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);
Related
I need to log in a user into Dropbox using Core API. Then remember his/her access token and allow logging in with another credentials (looks like a second Dropbox user). But when I make request to https://www.dropbox.com/1/oauth2/authorize it automatically ends up with redirect page with first user's access token giving no chance to enter another credentials. I know I can revoke first access token but then I will not be able to silently come back to first user.
Does anyone know is the possible to implement?
You can set the force_reapprove parameter for the /authorize page to true to prevent the automatic redirect:
https://www.dropbox.com/developers/core/docs#oa2-authorize
Note that the /authorize page is hosted on www.dropbox.com though, so the user will get their www.dropbox.com session, even if force_reapprove=true is set. With that parameter set though, the user has the opportunity to switch accounts, using the dropdown in the upper right of the page, before authorizing the app.
If that's not sufficient for whatever reason, you can try to end the user's www.dropbox.com. The simplest way is to direct them to www.dropbox.com/logout first. Be sure to make it clear to the user what is happening though.
Or, if you control the entire browser, e.g., if it's an embedded web view in your app, you can clear the browser's cookies, which will clear the session, forcing users to log in again.
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.
Well, you type username and password in form, hit "OK" button. Then data going to server side and check users database if that user is existed. Then it return user id. And what next?
That data is saved in cookies?
Does it mean, that with every clicked link, site login you to website again?
I mean,
you click some link on site
browser redirect you to that page
site checks your cookies
site grab username and password from cookies
site checks is that data is valid (via connecting to database)
show page to you
Is that correct?
User enters credential.
System validates credential.
Upon successful authentication, server saves user object into session.
System grabs user info from session.
System displays webpage.
Tadaa!! :)
UPDATE
To add a little more...
User visits the secured webpage.
System checks if session contains a user object.
If user object exists in session, allow user through to visit the page.
If user object doesn't exists, redirect user to login page.
You don't need to store user password in the session. In fact, it is highly discouraged. Checking to make sure the user object exists in the session is sufficient.
When the user clicks the logout page, then proceed to invalidate the session... that's it. :)
Almost correct. You rarely go to the database with every request. You usually set a cookie with a expiry date and save the user session and info in memory. So every time a request is made, if the user is not authenticated, you authenticate him, generate and send him a cookie with, say, 5h expiry. So, in the next 5 hours, whenever a request comes in with that cookie, you trust that the user is an authenticated, valid user and you don't have to check the database.
It's not how every site does it nor it is the only way to manage session and cookies but I think it is the most widely used.
You should probably use sessions, but that's pretty much the gist of it. That way the data doesn't accidentally persist.
I mean, for my simple site at home, that's how I do it. But it's still locally hosted, so the security is guaranteed to be crap.
Oh, and no need to check with the database whenever you click on another link -- too much time wasted.
Typically, an application takes advantage of the session that is established between the browser and the web server, and makes a note that that session is "authenticated". "session" is a built in feature of HTTP. If the browser is closed, or after a certain period of time passes, the session is automatically closed. If the user does an explicit logout, the application marks the session as not-authenticated.
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.)
I am currently building an internal web application used in a factory/warehouse type location. The users will be sharing a single PC between several people, so we need to have a fairly short session timeout to stop people wandering off and leaving the application logged in where someone else can come to the PC and do something under the previous user's username.
The problem with this is a session can timeout while a user is currently entering information into a form, especially if they take a long time.
How would you deal with this in a user friendly manner?
Keep the server informed about the fact that the user is actively entering information.
For instance send a message to the server if the user presses the TAB key or clicks with a mouse on a field.
The final solution is up to you.
Use AJAX to regularly stash the contents of the partially filled-out form so they have not lost their work if they get booted by the system. Heck, once you're doing that, use AJAX to keep their session from timing out if they spend the time typing.
The best advice would probably be to ask the users to close the browser window once they're done. With the use of session-cookies, the session will automatically end when the browser is closed or otherwise on a 30 minute timeout (can be changed afaik).
Since there by default is no interaction between the browser and the server once a page is loaded, you would have to have a javascript contact the server in the background on forms-pages to refresh the session, but it seems a bit too much trouble for such a minor problem.
If the session timeout is so short that the user doesn't have the time to fill in a form, I would put an AJAX script that makes a http request to the server, every few minutes, to keep the session alive. I would do that only on pages that the user has to fill in something or has already started filling something.
Another solution would be to use a session timeout reminder script that popups a dialog to remind the user that the session is about to time out. The popup should display a "Logout" and a "Continue using application" that makes a ajax request to update the session time out.
Maybe that a keep-alive javascript process could be helpfull in this case. If the script capture some key triggers, it send a "I'm still typing" message to the server to keep the session alive.
have you considered breaking the form into smaller chunks?
Monitor the timeout and post a pop-up to notify the user that their current session will expire and present "OK" or "Cancel" buttons. OK to keep the session going (i.e. reset the counter to another 5 minutes or 10 minutes - whatever you need) -or- Cancel to allow the session to continue to countdown to zero and thus, ending.
That's one of lots of ways to handle it.
Using a JavaScript "thread" to keep the session open is, to me, a bad idea.
It's against the idea of session timeout which exists to free some resources if there's no user in front of the application.
I think you should adjust the session timeout with the more accurate time, in order to fill the form in an "typical normal use".
You may also be proactive by :
having a JavaScript alert displaying a non-intrusive warning (not a popup) to the user before the timeout expire, which say that the session will expire soon (and give an link to send an ajax request to reset the timeout and remove that warning - that will avoid the user to lost the form he is currently typing),
and also have a second JavaScript "thread", which, if the session has expired, redirect to the login page with a message saying that the session has now expired.
It think that's the best because it avoid the user to fill a complicated form for nothing, and handle the case when the user has gone away.
As an alternative for the technical solutions, you could make your application in such a way that everytime a particular job is done, for example filling in a form, you ask the user if he wants to continue doing another job or if he's done. Yould could have a startscreen with menu options and if the user chooses an option he first has to enter his credentials.
Or put a password field on the form. Depends on how many forms they have to fill in a session.
When the user posts the form and their session has timed out, you should make sure you save the form values somewhere and then ask the user to login again. Once they have re-authenticated you they can then re-submit the form (as none of their data will have been lost).
I had developed something requiring very long session. The user logged in on a page when he sit on the machine and after doing his work, logged out. Now he may use system for few minutes or for hours. To keep session alive till he logged out, I used timer with javascript, it went to server and updated an anthem label with current time on server.