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.
Related
I'm developing an app in shopify app market
As you know, shopify apps work in iframe. I've no problem in session when i directly use the app in browser without iframe.
The issue is only within iframe.
I'll process oauth for shopify and redirect it to my app url inside the iframe. I'll set required session data if oauth is successfull.
But as soon as the page is redirected to the dashboard page after setting session. The dashboard page doesn't have the session data which i set earlier
In oauth success block, i used this to set session data
$this->session->set_userdata('variable', array('uid' => 15));
In dashboard page, i used this to get session data
print_r($this->session->userdata('variable'));
But here i receive empty nothing else.
I tried many solutions in the web regarding this issue
But their issue is with or without iframe.
I tried lots of solutions, but nothing worked for me
Fyi, CI Version is 3.1.11
PHP Version is 7.1.9 and also tested with 7.4.21
I tried
ini_set('session.id', $params['cookie_name']);
and manually commenting our session_start() and other lines in Session.php files and other stuff
Nothing is fixed this issue
Any help would be greatly appreciated
Our Spring application is used to book various services. Normally, our clients list their services in their Instagram bio. When a user clicks the link in the Instagram bio, our application opens up in the Instagram browser.
At a critical point in the flow a 403 is caught by our application. This 403 does not always happen. But when it does, it only happens for some users on an iPhone navigating in the Instagram browser. No other combination of device/browser causes it. This 403 is causing us major issues.
The CSRF token is included as a hidden element in the form that is submitted which results in the 403. Perhaps Instagram's browser sometimes ignores this token but how or why is beyone me.
Has anyone else experienced anything like this?
Thanks
I had this problem with one of my Ruby on Rails projects where people were navigating to a form directly from Instagram profile link, and once in a while we were getting 422's.
Logs showed that Instagram in-app browser submitted CSRF cookie that was different from the token in the hidden corresponding field in the form, which should not be the case, were the page loaded correctly in the in-app browser. We were able to replicate it live on one device, and from user's standpoint page loading and navigation looked completely normal. Could it be related to caching?
Previously we already had default Rails headers with max-age: 0, but decided to
simply set
Cache-Control: no-cache, no-store
for every critical page and see if it changes anything.
The problem seems to have disappeared since.
I am currently working on a small project using keycloak 2.5.0
I've already set up the user login and i'm now trying to implement a page wide logout button.
As the documentation states, is simply called the route
http: //my-auth-server/auth/realms/master/protocol/openid-connect/logout?redirect_uri=http: //application-root.com/
For the sake of simplicity i used an anchor tag to make this GET Request.
If i take a look into the Network tab of the firefox developer tools everything seems to be working fine. I am getting back a 302 status code for the redirection request. And after that, the application successfully requests the http: //application-root.com/ with a status code of 200 and redirects me to this page.
But when i want to request the locked content again (the one secured by keycloak) its still accessible.
But whenever i manually delete the JSESSIONID and KEYCLOAK_ADAPTER_STATE cookie after the redirection, everything works fine and i'm being logged out correctly. Sadly i can't delete those cookies programmaticly because they are HttpOnly
What is the expected behaviour of this request ?
Am i missing something ?
Has anyone experienced anything similar ?
Thanks for any help
I implemented logout using Keycloak 4.8.3 version. Mandatory parameter is id token (id_token_hint). Optional parameter is redirect url (post_logout_redirect_uri).
Example:
http: //my-auth-server/auth/realms/master/protocol/openid-connect/logout?id_token_hint=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJEY0gyNnl0OFV0OEJQTGxoR&post_logout_redirect_uri=http:%2F%2Fapplication-root.com%2F
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 !
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.