Decide how Stripes should run in multiple tabs

Description

At present, when Stripes is running in multiple browser tabs, each has its own session. This means, for example, that you can be logged in as two different users in different tabs – a facility that may prove very useful, as D can attest from her work with MKAdmin.

But for other purposes it would be nice to have all tabs using the same session: for example, if they were all logged in as the same user, then STRIPES-409 (right-click to open record in new tab) would be pretty trivial.

We need to figure out what we think the "correct" behaviour is. (And then, implement it!)

Environment

None

Potential Workaround

None

Checklist

hide

TestRail: Results

Activity

Show:

Mike Taylor June 22, 2017 at 4:01 PM

Yep.

Cate Boerema June 22, 2017 at 3:44 PM

Can we close this since we've decided how to do this (STRIPES-419)?

Jakub Skoczen June 13, 2017 at 9:45 AM
Edited

I am also with Jason here – syncing the state (as in UI state) between different tabs is beyond v1 and we will rely on data getting persisted on the server for a very basic state "sync".

Sharing authtoken should give us what we need to resolve the immediate problem (), I will file a specific STRIPES issue for it (STRIPES-419).

Mike Taylor June 13, 2017 at 9:03 AM

Thanks, Jason. Sounds like you have this quite well in hand. Maybe we should mark it for-next-sprint and invite you to look at it?

Jason Skomorowski June 13, 2017 at 12:26 AM

I think sharing much state between running instances of Stripes (eg. persisting the session) is beyond the scope of v1.

That said, we definitely need to share the auth token. This would mean that each tab is still completely independent of the others, but that's pretty okay as (by design) most of the data sharing is via the back end. In addition to being able to open new tabs without logging in again (absolutely must be possible), persisting the token in browser storage would allow us to close the tab and re-open it without needing to log in again if our token hasn't expired yet (unless we explicitly log out).

We'll want to store the expiry along with the token so the system knows not to try to re-use it and can fail gracefully.

Overall this should be pretty simple (famous last words), there are standard APIs for persisting the data (and we can abstract it behind https://github.com/localForage/localForage to avoid browser issues). The one tricky part is token renewal---tokens should expire and should be transparently replaced if you're actively using the system. What happens if you're switching back and forth between tabs rapidly and wind up with two Stripes instances requesting a new token? We can just discard the other one and use the one in storage if we see a new one has arrived but will both tokens still be valid? I don't know how the details of our auth implementation so rather than speculate I'll just loop Kurt into this conversation.

Done

Details

Assignee

Reporter

Priority

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created June 12, 2017 at 12:51 PM
Updated July 6, 2017 at 4:15 PM
Resolved June 22, 2017 at 4:01 PM
TestRail: Cases
TestRail: Runs