For specific reasons I'm logging the user automatically, and set the remember_me cookie so they stay logged in.
They hit a route like my-app.com/my-login?params=XYZ
I call Auth::login($user, true);
I redirect them to a page where they are logged in
It works everywhere, except on iOS Safari (for some reason). There, it logs in, but doesn't remember the user. However if I refresh the final page just after login, it remembers the user!
Any idea why? How/when is the remember_me cookie set in the HTTP response?
10 years from now it was a problem
Safari doesn't set Cookie but IE / FF does
Some Safari old versions like (v. 7.0.6) would ignore a cookie. The cookie header looked perfectly fine, almost identical to another cookie which was remembered.
The culprit was the previous cookie header having a malformed expires value. Safari's handling of broken cookie headers is evidently not as robust as that of the other browsers.
So try to use newer safari
Related
We've recently deployed a Laravel Application and experienced some weird issues with Some Safari Versions on our application.
When surfing on our applications, especially if the user is not authorized, we sometimes have on Safari the Problem that the XSRF-Token is not present within the Request/Response-Header.
On application Forms, the missing token results in a 419 Page expired issue.
The Problem only appears sometimes in some versions of Safari. Mostly a Reset Cache & Cookies fixes the Problem for 1 or 2 form request.
I did a complete reset of Safari
Allowed Cookie
Allowed Tracking
Disabled Plug-Ins
Technology
We use PHP 8.0 and the latest Laravel release. For the Frontend, there is a vue.js application with inertia.js as a connector. Regarding passing csrf-tokens to the Frontend, there is no further configuration needed to pass down the csrf-token. (Soruce)
I tried to capture the TokenMismatchExpection but no chance only the HTTPException works.
The question I have:
Does anybody experience similar problems? How can I prevent them?
Attached some Laravel Debugbar Screenshots.
left side Safari 14.03 | right side Chrome
Page expired screen
I ran in the same issue. I pinned the problem down to Safari ignoring the 'Set-Cookie' response header if the page was opened via a link from another site. (In my case, it's a link in an email opened in MailHog). If the link is opened in a new tab by hand, the problem is gone.
Due to the missing XSRF-TOKEN cookie, axios doesn't set the X-XSRF-TOKEN header in the requests leading to the 419 from Laravel.
So far I haven't found a feasible solution to inject the X-XSRF-TOKEN header by hand because the the VerifyCsrfToken Middleware expects the token to be an encrypted cookie.
I have a site with a separate REST API on a subdomain, e.g. api.mysite.com, that I send CRUD requests to. The API sub-domain has this filter adding the appropriate headers to the response:
// Simple CORS handling
Route::filter('cors', function($route, $request, $response) {
$origin = Request::header('Origin');
$host = parse_url($origin, PHP_URL_HOST);
// Don't send response for external domains.
if (!in_array($host, Config::get('domains'))) {
App::abort();
}
$response->headers->set('Access-Control-Allow-Origin', $origin);
$response->headers->set('Access-Control-Allow-Headers', 'Accept, Accept-Encoding, Accept-Language, Content-Length, Content-Type');
$response->headers->set('Access-Control-Allow-Methods', 'DELETE, GET, PATCH, POST, PUT');
$response->headers->set('Access-Control-Allow-Credentials', 'true');
});
I'm also setting crossdomain: true and xhrFields: { withCredentials: true } on my jQuery $.ajax request. The requests manage to go through to the server, hit the appropriate routes, etc, but something is going wrong with the authentication process. Every time, Laravel acts as if the user hasn't logged in, causing requests to Auth::user() to return null. Inspecting the requests in Firebug shows that the Cookie header is sent in the request with the Laravel session id, but the server responds with SetCookie, as if trying to start a new session. I'm probably doing something dumb here, but I'm at my wits end trying to determine just what.
Update: From some debugging, I've found something interesting out. Not sure what it means, yet. To get to the page in question, the user must be logged in. Therefore, there is a laravel_session cookie in the browser when the page loads. I then send off a couple of (cross-domain) AJAX requests by interacting with the page. The first request has no cookie set at all and gets a new laravel_session cookie set from the server. The second request then includes that cookie, but the response to it sends back yet another new cookie, as if the back-end never got the memo about the first. I'm starting to wonder if this isn't something to do with cookie domains or some-such.
I finally figured it out.
First of all, the xhr and route filter were both configured correctly. The root cause of this problem was definitely a cookie issue.
The cookie domain for laravel_session was not initially set. Browsers interpret that to be a short-hand for "current domain". That is, app.mysite.com What I needed to do was explicitly set the value in Laravel's session.domain configuration to be ".mysite.com" That way, the same session cookie becomes available to app.mysite.com, api.mysite.com, and any other sub-domains of mysite.com Problem solved!
That said, there were two gotchas that I tripped over on my way to this solution:
The first was that cookies cannot be set for TLDs. I normally set up my development domain to be something like "mysite", leaving off the TLD. As far as DNS is concerned, that IS a TLD, and the cookies will fail. Once I changed my fake domain for development over to "mysite.dev", "mysite" was no longer a TLD, and the browser accepted cookies for it.
The second was that I had to remove my session cookie from my browser before I could log in to the new and different domain. I don't know why this is the case, but remember to clear your session cookie out when doing this.
Obviously, this is too much to ask your users to do. If you're putting this kind of change out into an already deployed site, you need to consider how to get your users migrated over to the cookie changes.
Since Laravel session cookies are set with an expiry time not too far into the future, one option is to simply deploy such changes when your users are not very active and accept the app appearing to be broken until all session cookies have expired. Only your currently and recently active users will be affected and the "solution" is nice and easy. But your app is broken for a while.
The other option is to change the name of the session cookie away from "laravel_session" at the same time that you change the cookie domain. This way, the new cookie sits beside the old one while the old ones expire and your app remains unbroken.
Using Forms Authentication in ASP.Net MVC 3, it appears that the login cookie is cross-browser. When a user logs in in IE and then opens the site in Chrome, for example, they are already logged in. When they logout in Chrome and then refresh the page in IE, they have been logged out there as well.
Is this correct or am I moy loco?
How does this work? I didn't think browsers used a common cache for cookies.
They don't share cookies. Something else is going on. The logout can be explained in the way the server handles logouts though. If your server has a single cookie that is then invalidated all logins across all sessions will be invalidated making them all log in again.
After logging in (authorization) within my application a session is created and I am being redirected to correct location (SSL page). However, after clicking on a hyperlink (non SSL page within same application) I am being logged out automatically (authenticated session lost). I tested the same in FireFox 3.6 and the application is working as expected.
The above is only happening if i clear the chache from IE and log in. However, if I login for second time after just closing the browser the above does not occur.
Thanks,
Lihnid
Do you have the <forms requireSSL="" /> property set to true in your web.config?
If so, you may need to set it to false if you want the Forms Authentication cookie to be sent for SSL and non-SSL encrypted pages.
http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.requiressl.aspx
What do your URLs look like before login and after login? This kinda thing happened to me before, and it turned out that my authn cookies were having trouble with a domain change from www.domain.com to domain.com or visa versa.
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).