I was trying to test features in my website that is different based on the user. I tried logging in from 2 separate tab but it each time I sign out and login from a different tab the older tab gets signed out and logged in as the new user as well. I thought that the cookies that are stored in the browser are tab specific. Each new tab has new cookies but I was wrong.
Does browser store one single cookie for the URLs that are the same?
I know facebook and other services works the same way but I always thought that this was possible using some extra programming that facebook wrote to insure security
Related
Here’s what I’m facing. Currently, refresh tokens are stored in httpOnly cookie, and on every SSR, we refresh the token and send the whole response to the browser, the access token is only saved in memory, then the browser will continue for renewing it. The problem arises when we have 2 tabs, the access tokens will go out of sync. The initial tab’s access token will be unusable.
To work around this, we can either use localStorage to sync the tokens or use non-httpOnly cookie to store the access tokens. Or, manage tokens server-side, But both would have a problem, let’s say Tab 1 sent a request using the current access token, then I open Tab 2, the token is refreshed, Tab 1 request just reached the API, and the token is already invalidated.
I can’t find a proper solution unless we build more server-side logic into NextJS. Or perhaps if we don’t invalidate access token when refreshing and let it dies off the expiry. That way, we have ample time to fight the race condition.
Or, we retry all requests using exponential back off. Actually this kinda solves everything, and there’s a package ready for it. Except we’ll need to rewrite many parts to adopt the new library, and also there would be false alarms in the logs.
Or, we just ignore this and hope the race condition won’t appear, although it seems to me it’s going to occur pretty easily.
We are facing this problem in the company I work for.
Our solution is to store the refresh token in localStorage. If the token is regenerated, the other open tabs would detect a change in localStorage, retrieve the stored token (which now is a brand new one, generated by some other tab) and from that point on use it. The token is stored in memory until another change in localStorage is triggered.
To learn how to detect a change in storage: https://developer.mozilla.org/en-US/docs/Web/API/Window/storage_event
Honestly, there is no standard and robust solution to that as far as I know, and based on my research on the Internet.
Interesting problem. In single page apps each tab would be independent and have its own access token that it could store in HTML5 session storage or memory.
In server side web apps cookies are usually shared across all tabs and can cause conflicts.
I would try to follow the SPA model - there is no good reason why using your app on tab 2 should invalidate the token on tab 1.
They are different sessions and should be independent - as they would be if running one tab in Chrome and the other in Firefox.
Keep access tokens short lived (<= 60 minutes) so that after logout on tab 1 the user does not stay logged in on tab 2 for long.
For example one user Has entered to my site and my websocket server accepted the connection, then the user opens a new window, how should I handle that new connection, should I deny a user or treat him as a new user?, also it will take more loops to update the information in both windows, any hints?
I just can't understand this moment, please any explanation on how it should be most logical solution?
You should treat it like the same user with a different connection.
You can identify the user by a cookie value, or a value in the local storage that is sent after connection. If you refresh or open a new tab, it is still considered the same connection.
You can identify the connection by a random id in the url or session storage. If you refresh the tab, it will be considered the same connection and it will reattach.
If you are familiar with .NET, I have a small project about a Terminal Server via WebSocket that uses this approach.
In this example the same user can open independent tabs, and in those he is still considered the same user.
How can I prevent the user login into my website, even if he uses another login?
I can prevent in the same browser, using session/cookies. And also I can prevent the same user, using a DB solution.
But I dont know how to prevent with another browser and/or another user.
Does anyone has any ideas? Im actually using asp and javascript, but im open to another platforms.
Tks,
MC
Actually if user have 2 different accounts and uses 2 different computers from LAN(or WiFi on that matter) based network only solution for you is to insert into database open session ID and correlated IP, date time when session got opened.
You also need to make sure that you set open session to 0 once it get closed or just times out.
Session and cookies will help you only to prevent user to use same browser from same computer.
Using JavaScript I would like to automate the submission of data via a form POST to a website that requires a login. Using a browser, I am able to login to this site and create a session. On another tab of the same browser, I would like to open up a second tab on the same browser and load the page where my JavaScript resides and allow the JavaScript code to interact with the website session I created on the first tab so the data being posted is admitted as the session I am logged on from the first tab.
The purpose of this is to automate the posting of data to this website that requires login.
I have the JS that does my form POST automation. However the issue I am encountering is that the JS fails to post to the website because it does not seem to detect or use the session information from the previous tab and therefore thinks I am not logged in.
In short, how can I allow the Javascript http request running in one tab of my browser interact and take advantage of a session I have created with another website I have logged in in another tab of the same browser?
It turns out that i needed to add the withCredentials property to the xmlHttpRequest. Doing this allowed me to impersonate the cookies i already had set on the other tab.
I'm implementing a plug-in that's embeddable in different sites (a la Meebo, Wibiya), and I want to use Facebook Connect. The plug-in is supposed to be embeddable in sites with different domain names. Problem is, Facebook connect allows only one domain per application you register.
The question is, how can I have multiple domains for a single Facebook application, assuming:
When users "Allow" the application on one site, they won't have to "Allow" it on other sites as well.
Preferably, after the initial log-in, users won't see a pop-up opening on every site they log-in to (i.e. - I'd rather not open a link to my domain and do the log-in process from there).
Is there anyway of doing that?
If not, is my only option is to manage all the log-ins from a single domain and pass the cookies back to the original domains?
And if I pass the cookies between domains, how can I be sure that Facebook won't block this kind of behavior in the future?
I'd appreciate any suggestions, though I'd prefer an official solution over hacks, if at all possible.
Im assuming you are using facebook.php by Naitik Shah? Your widget would need to be on every page of course and include the async script connect-js.
I am currently developing a facebook login based application myself.
I would say the best solution is too login through your own domain and pass the cookie. Your app/widget will be the only one they allow to share information with. Nothing should be different in operation from a single page solution. I envisage a PHP plugin which executes a login from an outside domain and passes through the cookie to the site via the widget. return the cookie securely how you wish (except for something dodgy like storing it in a div and retrieving it..or something a hacker could try to spoof). the site will then use the cookie for account and user id purposes and the widget will control all login actions and session finding using the async script (but routed through a different domain).
Sorry I can't be more help but this is the only solution I can think of, and it seems you have already anyway.
In terms of keeping session control across different domains you only need the 3rd party cookie to be active. Once your page is activated for your domain you will already have the cookie for that domain if you haven't logged out or it hasn't expired. A benefit of using an outside management domain.
It would seem this is also the most reliable way compared to any successful hack for multiple domains, because I would see fb and Oauth2.0 as being ok with an approved party sharing info (cookies) to another party approved by the approved party. But.. It could be problematic if they think the user will have privacy issues, because you could potentially share the cookie on any site without the users permission. So you have to be careful about notifying the user about all the sites they will be auto logged into and treating them with respect.
Good luck with it, hope you let us know how it goes.
There is easy and clean technique -> Single Sign On (SSO). You can search on about it.