[SOLVED]How to Create Sessions for User Logins
-
Hi,
I have an application that contains Login Page that takes username and password, it will get into homepage. The Homepage contains links to view the records of users (like view profile of users etc). Now the problem is, if any user gets logged in he can view any user records. I want to restrict the logged user to view only his related records. For that what I need to use? Can anyone give any example related to this. This application is in Qt Creator 4.7.4 (32 bit) QWidget Project. Thanking you in advance. -
That depends a lot on how your application is built. I doubt a meaningful answer is possible with the little input you provide.
What is the "homepage"? What kind of protections are built into the system so far? What kind of protection do you need?
-
Hi Tabias Hunger, Thank you for reply. Here my requirement is simple. If any user logs into the application, I want to view the username/id throughout the application (like we maintain sessions in other languages).
The HomePage is a QMainWindow which contains menu items which redirects to different forms depending on the user selection. In the redirected form the user is having an option to view records by typing his username/id. Then he will get the records which are related to the entered username/id.
Here my problem is, if he enters any other username/id in the redirected form, he can view the records of other users. I want to restrict the user to view only his records according to his username/id which was entered in LoginPage(QDailog)
Thankyou
-
I think having a user log into an application is the wrong approach already: The user logged into the OS, so the application already knows the user. Why have him log in? You can rely on the OS to restrict access to data based on file system permissions and other OS level security mechanisms.
If you can not use the OS level security, then you will need to have a user log into a server, not an application. That server is then responsible for the security and may only serve data the user is authorized to access.
Having the data accessible (on the OS level) to a user and then using an application to limit the access again is bound to fail.
-
[quote author="Tobias Hunger" date="1348922346"]Having the data accessible (on the OS level) to a user and then using an application to limit the access again is bound to fail.[/quote]
While I agree with your overall statement I disagree with this one. Just create different configuration sets for each user which are encrypted using the username, the password and a salt. It will be practically impossible to access the data of a user if username and password aren't known, despite the full access to all the configuration files.
A server would be nicer, yes, but sometimes such sophisticated solutions are overkill for the situation at hand. -
DerManu: Oh, you are right of course, completely forgot about that one:-)
-
DerManu:
I can not tell you how to create your internal application logic, but it's just an internal filter problem. If you know the logged in user name, why allow him to search for other users?
-
[quote author="Gerolf" date="1349157310"]DerManu:
I can not tell you how to create your internal application logic, but it's just an internal filter problem. If you know the logged in user name, why allow him to search for other users?[/quote]Just an example: We have a special temperature stabilization system (think "airconditioning") for experiment tables which are directly controlled via various PLCs across the building. Those Systems all come together in one PC, where about fifteen people have access to control the PID parameters, setpoints etc. All others may only view datalogs or at most set parameters for their own labs.
This was realized by the company we've hired to build the system in exactly the way I've described above: One (highly limited) user account on the OS level and multiple accounts inside the controlling software with various complex privilege settings, including privileges to change certain privileges for certain groups but not for others, etc. And it's perfectly fine like that. If we had multiple user accounts on the OS level, every log/config/whatever would be saved to a user-local directory (e.g. /home/user1/.config, /home/user2/.config, etc.). This would make it cumbersome for users with higher privileges to, for example, examine log files of other users (to see who messed up some parameters again), because you'd need to tell the OS which user has access to which log and config files in the /home/* subdirectories. So you'd need some ACL which always needs to be synchronized (manually!) with the privileges in the software system. What a mess!To be honest, I only see downsides of outsourcing the user management to the OS level. You said "why allow him to search for other users". But we're not necessarily doing that. If you don't have username and password, you couldn't even find out what users there are in the system. At best you could find out how many there are, if the user data isn't in one big file but split per user.
And to make sure some vandal doesn't delete the entire user file: just make it and the software owned by a different OS user and set the suid bit accordingly. So the only way for the other limited OS user to interact with the file is through the software.
So you should have three OS users: root, softwareowner, softwareuser. And everybody, including the ones with maximum privileges in the sofware, only uses the softwareuser account. -
Der Manu: Such a setup is essential a server process running somewhere which does authorization for clients (running as separate users/on other hosts) connecting to it. That is fine, users have no direct access to the data the server anages for them.
My issue is having all the data accessible to the user (e.g. by using files in a shared folder for storage). Users can then go around the application and work on the data directly -- either because they want to do something that the application forbids them to do or because the user thinks doing changes manually is more convenient (mass edits or whatever). Sooner or later a user will do something stupid in such a setup:-)
-
[quote author="Gerolf" date="1349157310"]DerManu:
I can not tell you how to create your internal application logic, but it's just an internal filter problem. If you know the logged in user name, why allow him to search for other users?[/quote]
As Gerolf said It is a internal application logic Now I can control the user from accessing other records. I solved the issue by creating a file and copying the usertype and userid into the file at the time of login, so that i m able to view the userid and usertype at any point of time. So my problem is solve.
Thank you all for giving me the replay.