I'm kinda lost.
I see A LOT of TokenMismatchException exceptions in my production logs and all of them came from android devices (I log the useragent, ip, url and request method with every exception)
It's basically a simple landing page with form so I see no reason people might be on page for few hours (that'll cause session expiration). I also pass the XSEF-TOKEN cookie content using the X-XSRF-TOKEN header so this is shouldn't the problem
I tried using my iPhone and everything worked with: Safari (both private and regular modes), Chrome and Facebook inline browser
I also tried using my girlfriend's LG G4 using Chrome, Built in android browser and Facebook inline browser and it worked as well.
I temporarily disabled the csrf middleware for this specific route so people won't get errors but this can be really bad. So what should I do next?
I'm using Laravel 5.2, sessions driver is file (cannot do redis from the server the client gave me) and the sessions directory is writable. Lots of sessions are in the directory so this is not a permissions problem. PHP version is 6.5.18.
Thanks !
Currently I know that my setup is working because I was able to login properly using the basic HTTP authentication.
I used these properties:
security.basic.enabled=true
security.user.name=user
security.user.password=1qaz2wsx
security.user.role=USER
However, I want to relogin again. I tried clearing cookies (I assumed it was saved there), I checked my local/session storage and cookies in Chrome dev tools but it was blank.
I tried accessing my site in incognito and it asks me to login (for the first time since I only logged in to Chrome non-incognito).
How do I "kill" my session in Spring Security?
If you use basic authentication, the browser stores the authentication until you close it (or exit the incognito mode, if you used it). There is no possibility to delete the session on server side, since the browser would just reauthenticate. If you want to be able to logout, use form login.
I have an application that requires Windows authentication with fallback to Forms authentication. I built it in this way: http://msdn.microsoft.com/en-us/library/ms972958.aspx and everything works fine.
So basically I create forms authentication cookie for a domain based on the outcome of Windows authentication. The cookie is valid as long as the browser stays open. I do not have problems with that in Firefox or Chrome, not even IE8 on Windows XP machines. Unfortunately all Windows7 machines with IE8 experience the same problem: a login prompt shows up when you try to refresh the page after around 30minutes of inactivity. Even if I provide valid Windows credentials I still cannot log in to the application. Nothing helps, but closing the browser and starting it again. Then I am again logged in automatically and it will be fine as long as I stay active. After 30 minutes of inactivity - again log in prompt. After some research I found out that if I delete the auth cookie using developer tools (F12) and then refresh, I get automatically logged in without the prompt (just what you would expect from Windows authentication).
Does anyone of you have an idea what can go wrong and how can I get it to work correctly on Windows7 machines? Or maybe ideas on where to look? Is it IIS problem (I use IIS6 on Windows 2003 Server), client problem? What makes Win7 IE8 so special that it fails?
I don't know why it expires, but I managed to get rid of the problem. Somehow on IE8 on Win7 it cannot continue, because it tries to auth, but the old auth cookie is supplied. If I clean the cookies on the request and then forward to the login page, it works. It's not a solution to the problem, but at least the user gets re-authenticated...
I am building a small web application and in my application I am using the session object to store information across calls to server. This works quite fine in Firefox \ Chrome\ IE, but it seems to fail in Safari. In Safari the session keeps forgetting that I've stored values in it.
Why is this happening? what can be done?
The session is based on an id stored in a cookie. The server uses this Id to link to your session on the server. It's highly likely cookies are off here. Load up fiddler or turn on tracing to see what cookies are being sent over... You should see the one with aspnetsessionid in it, if not your browser prob has them turned off.
You may also want to take a look over here: Facebook API and Safari
Looks like, if any redirect is sent when you are establishing cookies, they will be viewed as 3rd party cookies and could cause issues with your server-side.
if your settings on Safari are set to not allow cookies, then this fails. I have just had the same issue on an iphone web app im writing. I enabled cookies and all worked fine.
The whole idea of the Session is that the values are stored server-side. Safari can't possibly cause the server to forget something. Either the value wasn't ever stored in the Session or Safari is failing to render the Session value.
Trying using a debugger to confirm if the Session holds the correct value when passing the value into the Session and when you're attempting to retrieve the value from the Session.
Generally speaking, when given a cookie that has no expiration period, modern browsers will consider this cookie to be a 'session cookie', they will remove the cookie at the end of the browsing session (generally when the browser instance closes).
IE, Opera, Safari and Chrome all support this behavior.
However firefox (3.0.9 latest proper release) appears not to follow this rule, from what I can tell it doesn't expire the cookies when the browser is closed, or when the user logs off or restarts the OS..
So, why does firefox refer to these as session cookies, when they last aparently indefinitely?
Does anyone know how Firefox handles session cookie expiration?
This is apparently by design. Check out this Bugzilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=443354
Firefox has a feature where you close Firefox and it offers to save all your tabs, and then you restore the browser and those tabs come back. That's called session restore. What I didn't realize is that it'll also restore all the session cookies for those pages too! It treats it like you had never closed the browser.
This makes sense in the sense that if your browser crashed you get right back to where you were, but is a little disconcerting for web devs used to session cookies getting cleared. I've got some old session cookies from months ago that were set by sites I always have open in tabs.
To test this out, close all the tabs in your browser, then close the browser and restart it. I think the session cookies for your site should clear in that case. Otherwise you'd have to turn off session restore.
Two ideas :
You have a problem with your session manager (the one included in FF3 or one included in an extension, like tabmixplus)
Use Firebug + FireCookie (https://addons.mozilla.org/en-US/firefox/addon/6683) to debug !
This should work. I used to be one of the cookie module testers, and I don't think there is any design reason this would behave differently (although if you crash, the session cookies might be designed to live on when you restart...)
Are you viewing the cookies in the "Preferences" menu > "Privacy" Tab > "Show Cookies..." button?
Also, have you tried a new profile?
I disagree with meandmycode above.
The HTTP spec https://www.ietf.org/rfc/rfc6265.txt talks about what a client should do with Set-Cookie headers with Expires:
If the server wishes the user agent to persist the cookie over multiple "sessions" (e.g., user agent restarts), the server can specify an expiration date in the Expires attribute. Note that the user agent might delete the cookie before the expiration date if the user agent's cookie store exceeds its quota or if the user manually deletes the server's cookie.
The logical extension of this is that the ONLY way the server has to require that the browser does not maintain a Cookie on exit is to set no Expires value (i.e a session cookie). If a browser does not honor that semantic then its not honoring the server's response.
Essentially the user agent is deciding to ignore the server request and act as if an Expires value had been set.
This is a bit of a concern in shared user environments. If I set a authentication cookie that is set to expire at the end of the session. This will persist in Firefox after the browser has been closed and another user starts up Firefox. Cookies are set with an expiry date for a reason!
I'm flummoxed that Mozilla have left this as it is for several years.
OK.. so I quit FF and switch off the PC.
Next day FF starts and opens the last set of pages (nice handy feature) BUT it restores the sessions and I'm logged back in to sites which have no "save my settings" feature.
I know because they are sites I built.
Whatever I do with php ini settings the sessions are restored.
They absolutely should not be restored.
Pages yes, but sessions with cookie ini set to '0' no.
I don't understand why this is not flagged as a security hole.
Sure I can do some additional checking on the server side, to see if a login should be allowed, based on time from last log in, but it shouldn't be needed.
A session should NOT persist.
FF is manipulating cookie expiry settings.
In my case, it was because of pinned tabs that automatically restored the session even if this option was disabled in Firefox settings. So if you unpin the tabs, the session won't be restored.
Well it is disconcerting to me. My system is set up so that users can hit EXIT whereby I destroy all session cookies. But if a user closes the browser without actually choosing to Exit, I'd like the session cookies cleared.
I actually tested it with Google Chrome, IE 9, and works fine. But Firefox is reluctant to kill this "session" (as reported by Firebug) cookies.
OK. This is what I did. I chose Exit from FireFox main menu and from then on, did it fine as expected (Dont know why).