The app is constructed so that the user first encounters a login page where he can enter his username and password, and the name of the server he wants to work on, [...] I use (abuse?) Dancer2's session mechanism to store all the relevant data from the server the user working on - and here is my problem. Dancer2's sessions are, in effect, per browser.

Your problem is your login page. Dancer2's session's aren't per browser. They are per browser, server, and TCP port. If Dancer2 uses cookies for storing a session key (most likely it does), you can set the cookies for a subtree of the document tree. So if you construct your URLs to look like http://loginserver.example.com/session/littleserver/..., http://loginserver.example.com/session/bigserver/..., http://loginserver.example.com/session/otherserver/..., and so on, and set the cookies path to include the server name (i.e. /session/littleserver, /session/bigserver, ....), Dancer2 should not confuse the sessions.

Alexander

I haven't looked at Dancer 2, but Dancer 1 uses cookie-based sessions, so I feel comfortable assuming that Dancer 2 sessions are also cookie-based.

While your suggestion of using more specific cookie paths is a good one, the OP should be aware that this would provide per-backend-server (or, more precisely, per-document-subtree) sessions, not per-tab sessions. So if, for example, you had two tabs open to bigserver, then those two tabs would still share a single session, even though it would be a separate session than the one in a third tab open to littleserver.

HTTP knows nothing like windows or tabs, just a user agent. And that's a good thing. Did you know there are several user agents that do NOT run in a windowed environment? I'm thinking of links, lynx, and Arachne. Also, most smartphones don't use windows.

So no, without very tricky hacks on the client side, you won't be able to have per-window sessions.

Perhaps private browsing mode may work, it should isolate the visited website from the other websites.

You could also create several Firefox profiles, and use several Firefox instances in parallel. You may need to add a command line parameter like "-no-remote" or something like that to prevent firefox reusing windows. (Or at least, it worked that way 10 years ago.)

Alexander

Its like a session id within a session id :)

a nonce appended to links/forms to prevent replay attacks and session riding... CSRF ... https://www.owasp.org/index.php/Session_Management#Page_and_Form_Tokens , Cryptographic nonce, Plack::Middleware::CSRFBlock, Dancer2::Plugin::CSRF, Mojolicious::Plugin::DeCSRF, ...

/foo/newnew .... issues a new nonce for the stack

All the links are nonced  /foo/nonce/view/id or some such