7

I am currently using window.sessionStorage to store a uniquely generated session ID. This ID is passed to all ajax calls to the server and persists across page navigation and reloads.

This seems to work perfectly for my target browsers, with one caveat: the duplicate tab functionality in Chrome.

Duplicating the tab copies the session storage to the new tab. When the new tab loads and communicates with the server, it now has the same "unique" identifier as the duplicated target tab.

Are there any ways that I can distinguish between the two duplicated tabs? Or are they truly duplicates and no information is different between the two?

Nothing persists after the tab/window is closed, so even a simple numeric tab id or anything would work as long as it is unique for that current instance.

incarnate
  • 81
  • 1
  • 5

3 Answers3

4

A variant of this worked for me:

https://stackoverflow.com/a/60164111/13375384

The trick is to only put the ID in session storage for the brief period of time when the tab is refreshing

In my TypeScript project, the solution looked like this:

const tabIdKey = "tabIdStorageKey"
const initTabId = (): string => {
  const id = sessionStorage.getItem(tabIdKey)
  if (id) {
    sessionStorage.removeItem(tabIdKey)
    return id
  }
  return uuid()
}
const tabId = initTabId()
window.addEventListener("beforeunload", () => {
  sessionStorage.setItem(tabIdKey, tabId)
})
Cody Herzog
  • 41
  • 2
0

Session storage is on the browser level, and not on the tab level. See https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage .

The only method I know of to identify a tab is to pass a paramater at the end of each URL (and even so you would need to use JavaScript to prevent open in new Tab).

Other methods would be unbearable, such as embedding an iframe in the app (and storing the identifier in the parent), but possible.

In short, you should rephrase you question to simply identifying a tab, and you will nevertheless not find an answer.

user1122069
  • 1,767
  • 1
  • 24
  • 52
  • I don't understand. The first paragraph in the referenced document states "Opening a page in a new tab or window will cause a new session to be initiated". Is this not a direct contradiction of what you are saying? I've relied on this distinction in practice to establish multiple concurrent sessions in different tabs. Now it appears to be broken in Google Chrome, and every new tab hijacks the session id of the existing tab. – Dave Causey Jul 20 '15 at 16:52
  • My bad. It looks like Google Chrome is still working as I expected, at least in some demonstrable cases. That is, if I open a new tab in the same browser window, it gets a clean sessionStorage context. If the tab is refreshed, it retains its sessionStorage context independently of the other tabs. I've seen some discussion of inconsistencies in other browsers, but as far as I can tell this is the correct implementation. – Dave Causey Jul 20 '15 at 17:16
  • As for the original question, it pertains to the "duplicate tab" mechanism, and I confirmed his observation. I never thought to use the "duplicate tab" mechanism to spawn a new session. I'll have to watch out for that. – Dave Causey Jul 20 '15 at 17:27
0

My eventual solution to this was to generate a unique ID on the server side which gets stored in the server session and passed back to be stored in sessionStorage. I also have another value (let's call it FOO) that is set on the client side and stored. Pretend it looks like this in a map:

{
    "unique_id" : "ABC123",
    "FOO" : "some value"
}

I send the values up to the server with every ajax request.

On page load, I check to see if I already have the unique_id, FOO pair in sessionStorage and load them. Any time the value of FOO changes, it will get compared with the server pair. If it has a different value then I store the new value for FOO under a new unique ID and hand it back to the client.

This doesn't 100% solve the problem, but it does make sure that FOO, which represents some persistent state, is never used incorrectly after tab duplication. The tab that originally had had the unique_id, FOO pair will continue to have that pair while the duplicated tab will have a new pair.

Technically, until the value of FOO changes the two tabs share the same unique_id, but as long as unique_id gets reassigned when FOO changes, they won't overwrite each other's state within the server session.

incarnate
  • 81
  • 1
  • 5