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.
Related
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!
In implementation of Login, I want to make sure if a user is already logged in one tab of the browser and opens the same web site in another tab, he gets redirected to homepage rather than the log in page. It's an ideal scenario as it happens in all the web site. I am achieving the same by storing logged in unique user token in local storage. Is it the best way to achieve it? Kindly guide! is it safe? If not how to go about it?
Just consider everything on the client as tainted or possibly manipulated.
So basically you should always check on the server side if the client has a valid session and only then deliver the homepage to it.
I would use a cookie set by the server side - just a random id bound to the actual client session on the server.
So the client could mess with that, but would have a hard time to guess another (also random) session id.
The cookie should be cleared by the server if the user logs out.
Then I would check on every call if he has a valid session id and if not directly send him to the login page by a redirect. Additionally you could then send him from the login page to the homepage whenever he is already logged in.
I've a group of employees whom use Outlook Web Access exclusively, and they are complaining that mailto: links on our intranet don't work for them because they don't open OWA (I can't change the settings on the individual machines, fyi).
I'm looking for some kind of way to have an intermediary page that I'll redirect them too when they click a mailto: link, which checks for an OWA login, and if it's found, will redirect the user to OWA. If no login is found, it will open a standard mailto: command.
MY PROBLEM: I can't seem to find a way to detect if they are logged into OWA. I can't use normal AJAX or Iframes because those elements are not allowed to inspect the contents of a page loaded from a different domain (our intranet is NOT on the same domain as OWA).
I even tried hitting the OWA url in code (C#) using the WebRequest class of System.Net, but I get a 400 error there for some reason.
I tried AJAX, IFrames and WebRequest against both the base URL of the OWA system, as well as the URL that you are redirected to for a login. All fail as described above.
Does anyone have a way of detecting an OWA login? I don't need to 'scrape' anything from a page in OWA, I just need a yes/no answer for if they are logged in or not.
Can you make a jsonp ajax request and just look at the 302 redirect url?
If you get redirected to owa/auth/logon.aspx, you are not logged in.
Using jsonp will let you work around cross domain security limitations.
I will explain my problem. I need to know if the steps below are correct:
The user enters their login details and these get submitted to the php server. If these are correct, I want to use the php code to start a session. However, because this is a mobile device I will be using html5 session storage. Now, my mobile website is all ajax based with no page reloads. So if the user submits the correct login credentials, I make an ajax response back to the user with what information? The SID/session_id of the session_start? Then, on the mobile device I place this session_id into the html5 session storage?
So, if these steps are correct, when the user then navigates around the website they are now logged in. And if they want to do something e.g. access a private page this creates an ajax request to the php server... this is where I am stuck. I assume that in this ajax request I send the session_id from the html5 session storage object, how does the php server use this id to prove the user is authentic? Presumably I need some kind of if statement and if it's not satisfied, send an ajax response back which my javascript will interpret as redirecting the user back to the login screen.
Many thanks if anyone can help me, it will be much appreciated as I am very stuck.
Note that cookies are not an option...
You could theoretically use HTML5 local storage to store the session ID, or transmit the session ID as a GET parameter in every request and pass it manually to PHP using session_id(), but I can't see the benefit. You might as well rely on cookies for this - they will be transmitted in Ajax requests.