I'm using PHP and allow users to sign-in. Once signed in, their ID is stored in a $_SESSION['LoggedInUser']. For certain transactions, they are directed to PayPal where they settle their payments. When done, PayPal returns control to my domain. So far so good.
Problem is that when they are returned, they are no longer logged in. Chrome, Safari and Edge drop the values of the sessions because of the domain change that occurred, although not consistently. I don't have any problems in Firefox, but would rather have the same code across the board.
I'm currently on PHP 7.4 and all browsers are pretty much up-to-date. Thanks for any feedback.
Matt
User is signed on, clicks on:
$link = https://paypal.com?....... // all details
PayPal returns to https://example.com/paypal_listener.php?------------- // all details
Now, same user is signed off
Related
I'm writing a website where the user logs in through conventional means. The login creates session variables so the site knows if and who is logged in.
There are products on the site that sell through Stripe. For ease I'm using Stripe's payment links. So you click a link on my site, it then visits Stripe's site to enter card details, then back to mine on checkout success.
My question is this: Are the session variables guaranteed to stay through that diversion so the user is still logged in when their payment is successful and they've been to Stripe and back or should I pass the customer id, etc. through the payment process and recreate all the session variables again once they arrive on the success page?
Yes and no...
The important thing to remember is that HTTP is completely stateless - every request is completely independent of any previous ones. As far as the web server is concerned, every time the user loads a new page that's equivalent to them "going away and coming back". Sessions work by telling the browser to associate a cookie with a particular domain, and then using that cookie to recognise that two requests came from the same user. As long as that cookie is still there, it doesn't matter if the user has visited another site in between, or opened a new browser window, or whatever.
However, it's a good idea to plan for what will happen if the cookie isn't there when they come back: customers tend to get very annoyed if you take the payment but don't complete the order. Another scenario to consider is that the payment completes but for whatever reason the user doesn't get redirected back at the end of the payment process (I've had this happen with malfunctioning security software on the user's PC, for instance).
A good approach if you can manage it is therefore to create a "pending" order in your system, with all the details of who was logged in and what they were trying to buy. Then you have a single ID you can pass through Stripe and receive for a successful payment. If the session disappears, you still know which order to confirm; and if orders get stuck in "pending" status for a long time, you can check in Stripe if a payment was actually made, and sort the order out manually.
I'm building an ecommerce website, and have had a problem with two different payment gateways. Visitors enter their card details and then leave to the 3D Secure step, which requires visiting their bank's website. When they return from that, they have no cookies on our website, and we cannot recognize them to link up the order.
With one payment gateway, this results in the order failing; with the other, the payment comes through, but is not linked to any specific account or products purchased. Clearly, both of these are problems.
I know that plenty of browsers clear cookies on closing the browser, but I'm not aware of any that clear cookies just because you've left the site for a moment. (Furthermore, on one of the two payment gateways, the 3D Secure step is done in an iframe, so the user hasn't even left the site.) It's the user's session which is disappearing.
Concrete questions:
Is it common for session cookies to be this volatile? This is behaviour I've been unable to replicate myself. Is there some common browser setting or addon which aggressively (and prematurely) deletes session cookies?
Might there be something else causing the effects I'm seeing?
Might there be something else causing the effects I'm seeing?
In this kind of scenario, these days it often has to do with the SameSite attribute of the session cookie.
The Strict value will prevent cookies from being send in any requests initiated by third party websites. When users are getting redirected back to your site from the payment gateway, that is “navigation” from a 3rd-party site then, and the cookies get not send; so your own session can not be picked up at that point.
Client wants to add functionality that allow one user to sign in only one place at a time. For example If I am login as maria.nausal#gmail.com then software do not allow me to login by using same email account in same system with different browser or different system.
I was handling this functioanlity by updating status of user but it does not work when user close browser button without logout.
Then I used onbeforeunload event for handling this type of issue. Everything is working fine in desktops but this event does not work in mobile device. By using Onbeforeunload,
If you have other solution that works in all environments please suggest me. Solution should be with session because onbeforeunload is also creating issue.
Thankyou
Your second approach also would not work with failing network connections or power cutoffs or a user simply closing his laptop lid. The whole approach is flaky, since it collides with the underlying web technology which is stateless. There is no way to clearly determine if a session is still used, since there is permanent connection but only single requests.
The closest you could get would be to timeout a session after a period of inactivity. To not ruin the user experience you should then take care to seamlessly reconstruct/reactivate the session in background without any user interaction required.
I don't think there is a foolproof way to do what you're trying to do. What other sites do (e.g. banking websites) is that they keep track of the time of your last activity. Then a certain amount of time after that last activity, they log you out automatically on the server side.
Add a field in the database, something to uniquely identify the browser, computer etc. (e.g. IP address) and record it when a user logs in. Then check that it is the same each time a user navigates to a new page. Thus, if a user logs in to computer A, and then logs in to computer B, the next time they navigate to a new page on computer A it sees that computer B is the last to log in and logs out computer A.
I am sure someone has run across this issue before, I just haven't been able to find anything on it anywhere. Anyway here is the scenario.
I have a PHP website that a user will login, then their account id is set as a session variable, then once they are in it basically acts as a single page app. The session account id is for tracking their activities as they do different things throughout the app.
The site will be accessed primarily on mobile devices. I have PHP that sets the session timeout length, then using JS, gives them a popup warning a couple minutes before the timeout ends. Then after the end of the timeout, using a meta refresh, it redirects them back to the login page.
On a desktop, this all works like it is supposed to. On mobile, it is behaving differently. On a mobile device, a user may login, do some stuff on a page, then without logging out, put their phone in their pocket and not come back to it for a couple hours. When they open up the browser it keeps them on the page they were on, but the JS was obviously not running during the time their phone was sleeping, or whatever else they were doing in the interim. The meta refresh as well also does not work as expected, but the session is still timed out. So when they open the app back up, and try to do stuff, I am getting errors in the DB saying that id cannot be empty.
I can use ajax to check if their session still exists on every click of a button, but for speed of the app I would prefer not to do that.
Has anyone else ran into this and found a solution for automatically logging out people on single page apps viewed on a mobile device?
Apologies if this question is already posted. I didn't find the answer i was looking for when searching through the related questions.
I have a login system I've just created that works with Facebook. Once the user logs in with their Facebook info and then I create profile in my database for them. I start a session upon successful login and store the user's id in that session. This setup so far has worked fine, but I've recently noticed if I try to login to the site on another browser (1xChrome, 1xIE, so on...) at the same time it wont let me. How can I fix this problem? I would like the user to be able to not only log into multiple browsers on the same computer at the same time, but if they stay logged in at home be able to still log in from another computer.
Any help is greatly appreciated!
Thanks!
EDIT: Yes I'm interested in allowing user's to log into multiple browsers as in 1xChrome, 1xIE, 1xSafari, etc. I should've been more clear. sorry.
You may want to do some more research into cookies.
Your users should not be able to use multiple instances of the same browser (for example, 4 Internet Explorer windows) to log in.
Your users SHOULD be able to use different browsers (ie 1 x IE, 1 x Firefox, 1 x Chrome or any of the above browsers + 1 with Private Browsing/Incognito/etc enabled).
The reason for this is because the cookie storage is different. You could technically use different Firefox profiles, too, I think...
... but to get back to your question - you might want to learn more about Cookies and their function in sessions.
The session should not be terminated, unless you do a check and terminate it yourself. An issue could be the actual facebook login. If facebook does not allow multiple logins(i think it does not), your first browser session will be getting an expired session( if you check on the facebook login status ), and this could cause your script to refresh the state of the first client (again, if you handle it like that).