I am building a webapp in Laravel 4.1, and I wish to force logout on browser / tab close.
A bit like your typical bank does... You log into your online banking, close the window, then go back to the site, you need to log back in again.
I have set the following in my app/config/sessions.php
'driver' => 'file',
'lifetime' => 0,
'expire_on_close' => true,
Safari and Firefox appear to work properly, however Chrome seems to keep the session cache as valid meaning that the user is logged in when they browse to my site.
Is there any way I can force Chrome to not keep the user logged into my site? Maybe there is something I can do in htaccess or similar?
As far as I can tell, Chrome does not have a specific issue when it comes to session cookies. I just tested my own app on Firefox, Safari and Chrome and the behaviour was the same for all three.
I would recommend opening up the Developer Tools in Chrome, clicking on the "Resources" menu and checking the cookies for your site. If things are working correctly, the cookie for your site should be listed with a value of "Session" in the "Expires / Max-Age" column. If not, then your app may not be setting the cookie correctly. Or you may have an old cookie hanging around, so just delete the cookie and try again.
BTW - Laravel 4.1 overrides PHP's native session handling and does everything itself, INCLUDING garbage collection. And it gets its session lifetime value from the 'lifetime' value above. So if you stick with your current settings, you are going to end up with ALL of your logged in users being logged out every time garbage collection runs (which, by default, will be 2 in 100 requests). You should change 'lifetime' to some value like 1440. I wrote a lengthy article on this problem just today in fact:
http://yetanotherprogrammingblog.com/content/laravel-40-41-session-configuration-problem-solved
Related
It appears from my research that the browser widget in Livecode does not record cookies, nor does there not seem to be other methods at play. Two pieces of evidence: in Livecode, when I return to a site that has previously alerted me to a cookie being set—having said yes the first time—it asks me again when I return to that site; item two: when I open Chrome’s cookie storage, I don’t see anything set after saying yes to a handful of sites. Could the browser widget be setting cookies elsewhere, like in a Windows folder? Or does the Livecode browser require some additional code to record cookies?
TIA,
NerdZero
When the app/stack is closed (in the proper way) the browser widget is destroyed together with all cookies that were set. Therefore it makes sense that next time when you create a new, fresh browser instance, that you get those pesky cooky warnings again. There is no way around it, except for perhaps executing a piece of JavaScript that automatically accepts any cookie warnings. This may be a real hassle to set up.
I don't think it is possible to read set cookies and restore them later, as such behaviour wouldn't be secure.
When I enter user id and password in netsuite every time it asks me my security questions , how can I stop this happening every time. Other people in my team are not having similar issue so I wonder what needs to be changed in my settings
*Note: I am not having administrator role
NetSuite saves a cookie in your browser in order to recognize your machine and browser the next time you log on. If it does not find this cookie it will ask a security question. There are several conditions under which this can occur:
You log on using a different machine.
You use the same machine, but a different browser.
You use 'private browsing' or 'incognito' mode.
You use a browser extension or other program which automatically deletes your browser cache, or cookies, when you exit.
You have your browser itself set to empty cache on exit. E.G.: Chrome has a setting to "Keep local data only until you quit your browser"
Anything else that might interfere with cookies.
You'll need to check which of these apply to you and act accordingly. If you're still unsure what could be causing it, you could reset your browser to defaults, or install a completely new browser and test whether it still happens with that. You may need to disable or uninstall any browser extensions too.
Question 1
My secure web application sets a session cookie for authenticated users which is not cleared even after I close my Chrome browser.
As a result, when a user tries to hit the dashboard page of my application after re-launching the browser (even restarting machine!), they are not asked to login again. Chrome is NOT set to "continue where I left off" which is also my next question.
I tested my bank's site under the same settings and it seems to force log out the user even when Network tab shows that same cookies are being retained (and sent with initial request header) for bank site as well. My server is Apache over SSL.
Can someone please point to some resource where I can handle this scenario because Chrome clearly is not clearing session cookie at the time of browser closing.
Question 2
Now with the setting "continue where I left off" where it basically persists your sessional cookies and practically you can remain authenticated forever, is there a way to override/work around this Chrome feature.
When I see even my supposedly secure bank site letting a browser bypass security like that, it kind of makes me unnerved. Any suggestions there?
Cheers!
What ended up fixing this issue for me was to uncheck the:
Continue running background apps when Google Chrome is closed
setting under the SYSTEM section.
Hope this helps save some headaches....
See update at end of question
In Rails 4 I understand that sessions are, by default, only supposed to exist for the browsing session. If you closed your browser, the sessions should no longer exist.
However, I'm not finding that to be the case. I have a Rails 4 app using all the defaults provided by Rails. I was working on some authentication code and ran into this problem.
When the user logs into the system, they have the option to "remember me" via a checkbox. When they check the box, the session should have an expiration of 2 weeks. The goal is that when the user logs into the system and closes his browser, he can then open the browser up again and use the app without having to authenticate again.
On the flip side, if the user does NOT want to check the "remember me" box and logs in to the app and closes the browser, when the browser opens again the user should be required to authenticate again because his session "expired" when the browser closed.
The problem is that my sessions never go away. I tested some simple code where on page 1 I set a session variable in the controller and then on page 2 I display that session. When I close the browser and go to page 2 (not page 1 so session is not set again), the session still exists as it did before.
I thought sessions were supposed to expire when the browser closed by default? I have also tried this with "cookies" instead of sessions and get the same result.
In short, how can I get a session/cookie that expires/dies when the user closes their browser? It doesn't seem very secure to me to have all sessions persist if the user doesn't want them to, and I'm not going to have my users delete their cookies everytime they close their browser (may be on a public computer where their login info should ONLY persist until they close the browser).
Update
I think I found what may be causing the problem. I'm using Chrome as my browser and I had it set to "remember where I left off" when the browser closes and opens. This seems to save all sessions/cookies. I verified this with Gmail as well. If you have the "remember where I left off" set, but don't set the remember me token in Gmail, Gmail opens right back up when you close/open browser. If you tell Chrome to open a new tab on open, then Gmail sends you to the login page like I expect.
So that solves one problem, but the overall problem still persists. How can I make this "secure"? Let's say you're at a public computer, and a malicious user sets the browser to "remember where I left off" when the browser opens. So you login to an app (such as Gmail) but don't check the "remember me" box. So when you close the browser you expect your login to be "secure". But if another user opens the browser back up, he's already logged into your app.
Is this something I can feasibly prevent? If Gmail has this flaw (with an army of very intelligent developers) should I be bothered that this situation exists?
The browser "remember where I left off" functionality was indeed the problem. Removing that option resulted in the "expected" behavior for my cookies/sessions.
I am working on a financial web application.
There is a client requirement that if user is logged in and already browsing the app. If he copies and pastes the browser url to another window. In another window, the user should get logged out.
I know http is stateless and there is no inbuilt browser mechanism (cookies etc) to solve it, this needs to be implemented by programming only. I guess people have already solved this problem. Do you know know possible solution to solve this issue?
Sadly, there is no solution.
The browser keeps the cookies and all of the user informations for all the Tabs & Windows you open. It will clear the datas (like cookies that ask to be removed after the session) as soon as you close ALL tabs and windows of your browser. Note that if the user use another browser, the behaviour your want will be respected — browsers dnn't (yet ?) share this kind of informations.
It is simply not possible to solve the problem with code, and you'll have to find work-around.
As a researcher, I've seen one of these solutions : de-auth the user on the HTTP_REFERER (Apache Env. Variable). As soon as the referer was not the application itself (except for the login form), the user was de-authed. But take care of it : the Referer is an info sent by the browser. And no information sent by the browser should be trusted :). The advice remains, if only you want to use Javascript. You'll find someone to use a JS-disabled-browser to bypass your verification.
That's why Application Development is not yet dead ;)
Cheers.
K.