Logging into separate running instances on same IP

[ianbattersby]

I think this is a cookie/auth issue, but here is the scenario:

1. Start a (clustered in my case) EventStore with 3 nodes all running on 127.0.0.1 but appropriately different ports (int-tcp, ext-tcp, int-http, ext-http - 127.0.0.1:2113,2114,3113,3114,4113,4114).
2. Log into first instance on http://localhost:2114 and browse it's data
3. Start a second (single in this case) EventStore pointing at a different DB location, running on 127.0.0.1 but with a different tcp/http port to the first (127.0.0.1:7113,7114).
4. Browse to URL http://localhost:7114 and w/o logging in browse it's data, but it shows the data from the first instance, not the second, as the session is still looking at 2114.
5. Log out of browser session and log back into second instance at http://localhost:7114, this time logging in explicitly to this instance, now shows data from second instance.

Although I appreciate running multiple copies on the same IP and different ports is unusual, it seems like it would be safer for the cookie/auth to handle this more explicitly? Perhaps it could store the connected instance port against the browsed port, and if these change, log you out?

URI: http://localhost:2114
Session: 127.0.0.1:2114

When checking session version these two elements remain in sync and log out if not. There if then browsing to http://localhost:7114 there would be a mismatch and the session abandoned.

[Gutek]

its a combination of cookie issue (its not port agnostic) and how we do auth.

hosting it locally with saved credentials - we can ignore cookie, and then we will have issue with asking user to auth each time.

we can use localStorage but this will then need to figure out somehow instance of UI...

i know this is painful however, i can see nice workaround without taking out some functionality from end user. @pgermishuys can you see some sort of solution here? we have cookie as Greg wanted and its a nice ux.

[pgermishuys]

I would like to play with the local storage solution again. There was a branch that addressed this very same issue, but I cannot find it locally.

I'll aim to get this in for 3.3.0 as well.