Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling auth and logouts across browser tabs.. #400

Open
mikepuerto opened this issue Sep 17, 2014 · 6 comments
Open

Handling auth and logouts across browser tabs.. #400

mikepuerto opened this issue Sep 17, 2014 · 6 comments

Comments

@mikepuerto
Copy link

Hello,

Was wondering if any who has implemented authentication can shed some light on how they manage logging a user out across multiple browser tabs/windows. I have implemented "isLoggedIn" middleware in my controllers and that works fine but say the user logged out from one tab and another is still open... on the page, in the "other" tab, there is a bootstrapped collection in the page source and they click on an item(rendered based on the collection)... it will take them directly to the item page being that the items model has already been cached by the fetcher.

Any ideas would be great! Thanks!

@demircancelebi
Copy link

I had the same issue, ended up adding { readFromCache: false } to every fetch call. My default fetch call looks like this:

    this.app.fetch(spec, { readFromCache: false }, function (err, result) {
      callback(err, result);
    })

Of course this means no caching for api responses throughout the app. So I would also be interested in with a smarter solution.

@mikepuerto
Copy link
Author

Yeah, I'm trying to avoid that as I like the cache :) I'm considering using socket.io to notify the other tabs/windows and just relaod the app... but I'm honestly not liking that approach either :/

I'll be working on this for the next 12 hours or so.. I'll let you know if I come up with anything.

btw- how are you authenticating and managing the session?

@demircancelebi
Copy link

I am not sure if that is a good pattern but, I have client_id and client_secret in my config files. I use these two to get client_access_token from API and I save it to user's cookie.

When user tries to log in, I send that client_access_token along with username & password, and got access_token back from the API.

I also save access_token to user's cookie and add it to every API call as a header in my extended version of restadapter. API checks this access_token header and returns the appropriate data.

@mikepuerto
Copy link
Author

This is basically what I'm doing as well.. as of now, the only thing I have figured out is forcing requests for everything or using socket.io... personally, since I'm in a crunch I'm just going to have socket.io broadcast a message to any other clients associated with current session to destroy it.

I wish others would weigh in.. @spikebrehm maybe?

@crwang
Copy link
Member

crwang commented Sep 22, 2014

Hi @demircancelebi, I do the same thing and it's a pretty good practice. It's essentially the same thing our mobile apps do as well.

@DuncanMacWeb
Copy link

Hi @mikepuerto, this may or may not fit the bill but @bevacqua published a technique in Cross-Tab Communication that uses the storage event fired by localStorage to communicate exactly this sort of thing across tabs without surplus HTTP requests (HT Open Web Platform Daily).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants