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>
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
I have a Webapp (HTML, JS, PHP) on an Amazon cloud server which is integrated in our companies network. Lets say the servers name is
dev-myapp.cloud.myentity.mycompany.com
This app is using the companies global SSO login by getting an oauth token from the SSO login page and then sending client, secret and callback (as usual). If Login is successful, the SSO login redirects to my callback (which in that case is my apps url above)
The SSO login creates many cookies in the browser. Most of them are flagged as secure but also some are not. For all of this cookies I now get an error
Cookie "xxx" will be soon treated as cross-site cookie against "path_to_any_of_my_sources" because the scheme does not match
I get this error for every script which is loaded (HTML, js, PHP, css) with FireFox.
The domain of the created cookies is
mycompany.com
so there should be no cross site at all.
What can I do to remove this hundreds of warnings, which makes debugging really annoying
If you need more information please let me know. Please understand I cannot provide you with real data from my company.
I was able to fix this same problem by clearing my cookies in the browser.
We have an issue with a asp.net core 3.1 MVC application. The application is using the built in asp.net Identity feature. The application is working well for existing users. If you hit any [Authorized] route, you are redirected to the login page as expected.
However, rather than have a registration process in our app, for new users, we onboard them via Stripe Checkout. Upon successful payment, stripe redirects to a specific route in our application /conversion/success/{sessionid} where sessionid is the Stripe session. This action is marked as [AllowAnonymous].
We then pull the necessary customer details from Stripe, create a user in our repository via UserManager<T>. We then call SignInManager<T>.SignInAsync() to sign in the new user, before redirecting the new user to the [Authorized] home page.
This process works perfectly when running locally on our test machines. Also, when running on our production server (Azure App Service) it also works perfectly when we hit the route manually through the browser.
However, when we actually run the process through Stripe, complete a payment and let Stripe redirect the customer, we get a strange behaviour.
The conversion route is hit, the user record is created, the sign in process completes but upon redirection to home page, the authentication middleware takes over, says it's not authenticated and redirects to the login page.
Just to compound matters further, if you then simply type in the home page route in the browser, the user is in fact logged in exactly as expected and the application works perfectly.
Using Fiddler to intercept the calls and look at headers, etc. we can't see why there would be a different behaviour when coming from Stripe as opposed to typing directly. We've even tried redirecting from a different website to our registration process and that works as expected too.
Any idea why we are seeing this behaviour?
---- Update ---
If, rather than redirect to home page at the end of the onboarding process, we simply show a simple View with an anchor link to home page, the user can then go to home page as expected.
Is it possible that you're rendering the page before authentication has been completed? Since UserManager uses a cookie to establish the user's session, authentication needs to complete before any response headers or body is set so that the Set-Cookie header can be sent in the response.
Based on what you described it sounds like the user is hitting the homepage after the redirect without having the authentication cookie. Where I'd start debugging this is by using your web inspector with "Preserve log" turned on and going through the Stripe Checkout process. Then, inspect the headers sent to the browser when you land on the redirect page & make sure the authentication cookie is set.
Between requests to Stripe and SignInAsync it seems possible that there might be a missing await, so the redirect is happening before the authentication context is updated. Hard to say more without seeing your code!
I've had some odd issues lately where after logging in to my application, rather than seeing the expected page, I get a json response rendered in the browser.
What's happening is I have a javascript routine on every page of the application that polls via ajax for new messages for the user.
There is a point when the user has signed out manually.. or is logged out when this ajax call is made and spring security is remembering this URL as the URL to redirect to again when logged in. So when the user signs in again, instead of being redirected to their dashboard, they are presented with the JSON response.
I need to prevent Spring Security from remembering Ajax called URLS, can anyone tell me if this can be done?
I have no idea if anyone experience this, i have a slight problem when redirecting from paypal to my site back....
I have a site built with angularjs + php in the backend of it, i log in to my site and everything is fine, When i try to do a recurring payments, it redirects to paypal, i accept the payments and such, when i come back to my site (review payment) i have in the url the payer id and token, which is exactly what i need.. but im not logged in anymore to my site.
The problem with this is, if i do reconnect to my site again, and do the same procedure, now it's all good...
What can be the cause of my site to log out the user when it redirect's back from somewhere, in this case, from paypal?
Take a close look at two requests from the browser to your website:
- the last one before redirection to PayPal
- the redirection from PayPal
Open the Network tab in FireBug or Developer Tools, depending on your browser, and examine the values sent in cookies.
Check if your browser accepts cookies (assuming it's cookie-based sessions you are using)
Make sure there is a cookie created by your PHP when you make the first one
Make sure it is still there, sent from the browser when you come back from PayPal
Make sure the values in the cookies (session ids) match
Also, that the server does not send a "set-cookie" header in the response to the second request
A "no" to any of the above opens a few more options to investigate, so start with these.