How does one use sessions cookies to manage logins?
The naive approach using, say, ASP.NET Forms Authentication sets a cookie when a user logs in. Cookie is then checked on every call to the server.
But cookies are shared between browser tabs. This seems problematic.
I log in as Dave in TAB A and proceed to do all work as Dave.
More or less simultaneously, I log in as Alfonso on TAB B. The cookie from this login overwrites the Dave cookie.
So all work in TAB A is done as Dave, the "Logged in as" UI element says Dave, but when I submit, the server performs all work as if it were done as Alfonso.
This does not seem good. What is best practice here? Is the only solution to use cookieless sessions by putting the encrypted username in the URL of each call?
The best practice is to ensure your logic properly handles authentication. This is a common problem, as you need to account for issues like this, as well as "what happens if I submit the form even though the user has since been logged out?"
You shouldn't be able to login as Alfonso when you are already logged in as Dave. You have to logout as Dave first. If a login screen was already present on a tab even though Dave is logged in, the postback from logging in should realize that the user is already logged in (so Alfonso can't login).
Every time you save data, you should ensure the person performing the work is 1) still logged in and 2) the correct person.
If you want some old tab to automatically realize the user has since logged out, or is now someone else, that would require a bit more work (AJAX)... without it, bullet 2. from above will handle your problem.
Related
I authorized the group of a user to the cockpit-application. I gave the group full access to the Process Definition and Process Instance authorizations. (so pretty much as described in the documentation)
When I try to log the user in, I see the Welcome screen and in the application overview the option to navigate to the cockpit-application.
However, when I click this, I get the Login screen again.
For a fraction of a second I see the cockpit application, but then it immidiatly redirects to the login page. When I try to log in again, it keeps redirecting me to this login screen.
I configured another group to use the Tasklist application and that is working as expected.
I tried to give the authorization on user-level instead of group-level but the same problems occurs.
(n.b.: I am using the Spring-Camunda-Starter for this application.)
I found the problem, I accidentally removed one of the authorizations the system automatically creates when the user is created. I think I might have removed this, as I thought it was not necessary.
It is in the User Authorizations, every user has an authorization from it's own user to that user. When I added this, it fixed the problem.
I found the solution when another user logged in and had no problems. And the found this to be the only difference between the two accounts.
Hopefully this will help someone in the future!
I have designed a standard login screen in ASP.NET like below:
As usual when operator selects “Remember me”, we expect system to not ask operator for credentials anymore and go directly to default (home) page.
My business team saw something on internet and they believe that when “Remember me” has been selected we need to pre populate the username and password and wait for customer to press “LOG IN” button:
I haven’t seen this practice so often and I am not very comfortable to do it. Although, I don’t have a good technical argument to explain and change their mind.
I am basically looking for good argument to explain cons and pros of above scenario.
Never ever should you pre-populate a passwords edit field. If you do so, everybody is able to read the plain-text password, if he can open the login form on this computer. A few minutes on an unlocked office computer would be enough to check the browser history, afterwards the attacker can login whenever and whereever he wants.
If you have a remember me function, and the user has logged in using this function, then there is no need to display the login form at all. You can just display the content. In this case, an attacker can do things with the account, but he cannot login unnoticed later from somwhere else.
I think (hope) you saw the pre-populated password field, because the browser filled in the content, and not the website did it. Maybe there is a password manager installed.
I have a web application where I want users to only be able to use it from one location (meaning a user can't actively be using the application at two locations). Currently I got this working in a very common way by only allowing 1 cookie session to be valid and removing any existing ones when a user logs in. Unfortunately I've been told that my method of only allowing 1 cookie is unacceptable because my users move around a lot to different sites and are tired of having to login every time. An easy solution would just be to allow more than 1 cookie, but I can't do this because I need to make sure a user account is not being used at two locations at the same time.
I'm wondering what is the best way to implement a system like this where a user can't be active at more than 1 location, but shouldn't necessarily have to login at every location they visit.
One possible idea I had was to allow multiple cookies to be recorded, but once a cookie becomes active (meaning I notice that session navigating the application) all of the other cookies are locked out for a certain timelimit like 15 mins. If no cookie session has been active for 15 mins then allow any cookie to login and gain dominance over the others untill it exceeds the timelimit.
Edit: It's ok for them to remain logged in after they leave a location
One way to do this is to log their last ip address and at what time that access was. On each access, you can check their last access.
If the last access is from the same ip, let them through.
If the last access is from a different ip, check how long ago that was. You can then define a cut-off point for how long they need to be idle before they can access it from another location. 15 minutes seems reasonable.
All of this can be done on the backend and this would possibly provide a higher level of security.
The browser allows users to store their credentials. Let them use this feature to log back in without hassle.
No need for a timeout. Allow multiple cookies, but only one active one.
Instruct your users to close the application when they leave their workstations. Make this something that's easy to do. Put a close button on each page or perhaps catch onBeforeUnload and notify the server that the page is no longer being displayed. Do keep the session when the user closes the application, but mark it as currently inactive.
When you get a request with a cookie that belongs to an inactive session, activate that session without complaints if the user has no other session active.
If the user still has another session active, something fishy is going on. So remove all sessions and send the user to the login screen.
(That'll teach them :) )
I have a problem with my authentication in CakePHP. Whatever I try, Cake will either tell me I'm de-authenticated after each request, either I'm still authenticated, even though I closed the browser before.
I'll explain in a few words how my authenticating system works. The user logs in, with either remember me checkbox checked or not. If it's checked, I will create a cookie so as the user is auto-logged in the next time he visits the site. Basically, when the user closes his browser, I need to delete all the session cookies Cake stores in the browser. This way, when the user comes back, he sees the login page if he didn't want to be remembered, or is automatically logged in from the remember me cookie if he chose to store it.
The problem is I played with both Session.timeout and Security.level from core.php, with no positive results. If I put the timeout to 0, Cake will de-auth me after each request and I'm not able to view any page so. If I put any other value for timeout, the user might close the browser and when he re-opens it, he could be still logged in, as the Cake session didn't expire.
In conclusion, how can I automatically delete the session cookie whenever the browser is closed?
Take a look at this article maybe can helps you, I use something similar for other purpose.
http://bakery.cakephp.org/articles/admad/2009/09/02/how-to-bend-cakephp-s-session-handling-to-your-needs
see: ini_set('session.cookie_lifetime', 0);
how do I prevent my users for more than one simultaneous login per account. I am using Vb.Net SQL.
Just coming from a 'web programmers' point of view, there is one really simple way:
You have to use some sort of central session system, where a Cookie on the user's browser has a hash, or some unique key that is also stored in the database. One each page request, or at set intervals, you check if that hash exists in the database.
Then, whenever you have a user log in, you delete any hashes that are tied to that user in the database, and then you create a new one for the user logging in.
What happens is if a user logs in, and you delete existing hashes from the database, then the other user will be logged out when you go to check for their hash in the database.
Not VB-specific, but: when the user logs in, keep track of the fact they are logged in. You can keep this in a cookie (watching out for the fact that a cookie can be tampered with.) You can keep track of it in a session variable. Or you could keep a boolean field in the database, "is_logged_in".
Then, when the user attempts to log in, you can check to see if they've already done so. If they're already logged in, the script might just return them to the home page (provided they used valid credentials. Otherwise a rogue user could type a username but leave the password blank, and depending on the behavior of your program, could see if a user was logged on at that specific time.)
Also, it is common that when someone is logged in, the webpage itself replaces the "Login" link with some text that says "Welcome, rascher!" and maybe links to their profile or preferences page.
Edit: Also remember to set is_logged_in (no matter how you track it) to "false" if they log out. It might also help to time this out - say, when the user closes the browser, or after "n hours" of inactivity (though that can be really annoying.) It will depend on how long people are generally logged into the system. Also note that someone might log in on their home computer, stay logged in, and then try to log in to the same place from work or their iphone. You might could look at ways of dealing with this (if the IP address is different than the current login, then log the other person out? Or something.)