I have a problem with my websphere portal set-up. When I log into my portal more than ones from the same browser ( one user per tab in firefox ) they seem to share the same session so if user A logs in first and then user B, user A disappears and gets user B session. Any one got any ideas why this could be happening. Same goes for if i try to log in the same user twice with the same browser when one tab logs out both will be logged out.
Best Resgards Anders Olme
You appear to be confused about how "sessions" in web applications work.
HTTP itself is stateless, i.e. it has no concept of a session - each page request is completely independent.
Sessions must therefore use some mechanism layered on top of HTTP. There are two basic approaches:
If you use cookies, your server sends a small piece of data to the browser (usually a session ID), which the browser will send back when queried. That allows the server to recognize the browser requests as belongig to some session, but as cookies are global to the browser (not per-window or per-tab), there's only one session per browser.
Individualized pages means that on each page server, every link has the session ID embedded, such that every page request has in its URL the session information. That way the server again knows what session the request belongs to. This allows several sessions inside one browser.
This is probably because the site in question is using a cookie to store your session information. Because of this you can only have one session per browser. In order to be able to have different sessions per tab you'll need to use a session state server to hold session information.
In IIS you have the option of doing this in a SQL database, or via a session state server which is a special server running session state. I assume websphere portal has these options as well.
You can get around this problem by logging onto the portal under two separate domains pointed to the same machine, so the cookies don't get shared between portals. No shared cookies = no shared state between sessions.
Depending on how your portal is configured to set cookies, you might be able to do it using two separate subdomains - or you might have to use two completely different domains if your portal is setting cookies to work in *.domain.com. If multiple portal domains are not available on your DNS, you could just go into your hosts file and create some dummy domains to point at the portal IP address.
