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
Related
This issue only seems to be affecting Firefox, and then only some users (with no obvious version/security setting differences). We are getting session loss in our Laravel app.
We have a payment integration that uses the iframe Opayo server integration. This opens up the payment form in an iframe in the Laravel app. Payment details are provided, and the payment is successful - including hitting an Opayo webhook to confirm the transaction.
The webhook returns a redirect URL, that Opayo uses to redirect the user (in the iframe naturally). This redirect URL is simply a URL on the same site as the app (i.e. the iframe parent).
At the point that the iframe loads the redirect URL, the site session is immediately killed. Originally, the page at the URL broke out of the iframe (set window.top.location), and also did some ajax calls - I removed both these actions, to confirm they weren't somehow responsible for the session getting nuked.
The site is served over HTTPS with a valid certificate. A session cookie is set to secure, HTTP only, and the same site is 'lax'
What could be causing this behavior?
This is because the iframe is not exactly your page running on your system. So, if the iframe is not on your system, it will not have access to the cookies that are in your application.
If the iframe is from your application, I advise you to use query params in the url of the iframe to pass such necessary information within the iframe. Something like:
<iframe src="https://www.foo.bar?value=1&value_2=2"></iframe>
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've spent about a full day attempting to get a very basic Spring Boot app with Spring security up and running to no avail. I cannot find a single example of code that works when I run it.
This example is from spring.io. Here is what I'm seeing in that example:
I start at http://localhost:8080 and see the welcome screen.
I click a link to http://localhost:8080/hello, which redirects me to http://localhost:8080/login.
I enter "user" and "password" as specified in WebSecurityConfig.java, which redirects me back to the welcome screen. I was expecting to be redirected to http://localhost:8080/hello.
When I click the same link to http://localhost:8080/hello I get the login screen again.
I've tried debugging via #EnableWebSecurity(debug = true) but there are no errors.
The above experience is endemic of what I experience when I download every example. Admittedly I'm new to Spring, and presumably I'm making some kind of newbie configuration mistake. Any help would be greatly appreciated.
I downloaded the code and ran using maven and it works perfectly fine. After logging in, for all subsequent page loads of http://localhost:8080/hello loads the page and not the login page again unless of course I log out. The problem you have mentioned may be caused by ( with quite high probability since you have mentioned it's endemic) is that your browser may be having issue with transmitting the default JSESSIONID cookie (which is set on first page visit and updated ( as good security practise by Spring security) on first login. For subsequent visits same JSESSIONID is sent to the server and it is a key for the session object stored on server which contains the now authenticated/authorized user. If some how this cookie is not transmitted back to server ( one reason could be it's disabled in browser setting) then your application (protected by spring security) would not know that you are an already authenticated user and will show you the login page again. For e.g, for Chrome you can see the cookie settings at Settings --> Content Settings --> Cookies --> Allow sites to save and read cookie data (recommended). You can also view the cookie header getting passed on each page load post successful login by using Developer tool in respective browser.
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.