Cookie is empty in the console - cypress

I am testing a website and on the payment page it gives me a checkout error and I realize that the cookie are empty in the console, what can I do?

Related

Laravel session killed when opening site in iframe in Firefox

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>

asp.net core 3.1 Identity - redirecting to login after SignInAsync() when referrer is Stripe

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!

Why doesn't the login session "stick" when login in using "ionic serve" window but works when I point the browser to the www folder?

I am using Ionic to build a login system on top of Codeigniter/Ion_Auth/codeigniter-restclient and when I try to login from "ionic server" the login works but the next api request to the logged_in() method returns false.
The same thing works properly when I point the browser to the www folder.
So here is the problem step by step:
run ionic serve
you see the login form (http://localhost:8100/#/app/login)
enter email and pass
the rest api returns "login successful"
$state.go('app.profile') works and redirects to http://localhost:8100/#/app/profile
REST get api/logged_in returns false and I redirect to the login page
If I do the same in a regular browser, step 1 becomes: open browser and go to http://localhost:8888/App/www/#/app/login, at step 6 REST get api/logged_in returns true and I don't get redirected to the login page, I stay on the profile page.
The code is the same. So my guess is that maybe ion_auth doesn't get the cookies it wants or the session is reseted. I am not sure at this point what the problem is. This is my first Ionic/App project so I might be missing something about the proper way to authenticate from a mobile app using code that works in browsers
Thank you
UPDATE:
It seems that when using the 'ionic server' window every request to the API triggers a new session. The new session is stored in the database and ion_auth tests the logged_in against that last one, which doesn't contain the login details.
you were taking about REST api and cookies and sessions. Cookies and sessions don't go with REST philosophy. Here is why.
Let me tell you how we accomplish this problem in our project. Basic way of knowing which user is requesting and if it has the access rights is by the 'Authorization' header value. You can use Basic Authentication, Barer or any other.
We generally prefer token based authorisation system. When a login is successful, server sends a token. In ionic app, we save it using a factory called SessionService. So whenever user logs in, token is stored and is used for every request. But token would be lost if user closes the app. So we can store it in local storage. User can then be directly redirected to dashboard until user logs out.
app.factory("SessionService", function($window){
var user={};
if ($window.localStorage['user']!=undefined){
user=JSON.parse($window.localStorage['user']);
console.log(user);
}
return{
isLoggedIn:function(){
return !isEmpty(user);
},
logout:function(){
console.log("logout")
user={};
$window.localStorage.clear();
},
setUser:function(data){
user=data;
$window.localStorage['user']= JSON.stringify(user);
},
getUser:function(){
return user;
}
}
})
Now in every web request, you can call SessionService.getUser().token when setting value Authorization header.
UPDATE:
Despite using cookies is not recommended, you can use it in your application easily.
If you are sending request with CORS, angular doesn't sends cookies with request.
One of the way address this issue is to send withCredentials: true with every request:
$http({withCredentials: true, ...}).get(...)
Read further about this here.
Hope this helps!

Paypal redirect logging me out of my site?

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.

403 Page to Login Redirect for Joomla 2.5

I have followed the steps from the this link: http://docs.joomla.org/Auto_redirect_guests_to_login
After I try to log in either as a guest or as admin, it gives me the 403 page. After I retry to login, I notice that it has already registered, but it cannot redirect to the correct page. In my case to the CREATE ARTICLE page.
In the beginning it worked for 2-3 logins. After that something happened and it doesn't work. I log in, it tries to redirect and fails, although it sees the redirection url. If I try to log in from the redirection link again, it prints AN INVALID TOKEN message. If I try to log in from log-in page again, it shows that I am already logged in.
Redirection doesn't see my logging, and because my redirection page is for registered users only, and the system doesn't recognize my logging, it prints the frustrating 403 page.

Resources