Andy wrote:
> When I was using previous versions of IE with XP and Vista I was making the
> Yahoo email login my start page and opening the IE was taking me to the Yahoo
> email login.
> After loging into one of my Yahoo email accounts I was opening a new
> instance of IE and it was showing the Yahoo email login page again, so, I
> could login to my another email account and switch between the email accounts
> simply by clicking on different open instances of the IE.
> Now, with the IE8 when opened it is already loged in to an account I was
> loged in before, and every instance of IE8 opens loged in to the same
> account, so, I have to logout from one account and login to another.
> What settings should I change in order to use IE8 like I was using my
> previous versions of IE before?
> Thank you.
You have to load a new instance of the web browser to ensure isolation of
sessions IDs between them. Running child browser windows or using tabbed
browsing will result in session ID collisions amongst them. In general,
tabbed browsers do not create new instances of the web browser process to
isolate their session IDs. The session ID collision problem exists in any
web browser that does not load a separate process for each child window or
tab. It is possible to put the session ID in the URL but that is a
potential security hazard.
To have multiple concurrent logins to a web application, load a NEW instance
of the web browser (do not just have an existing instance open another
window or tab). In IE8, use the "File -> New Session" menu, or run
"iexplore.exe -nomerge" at a command prompt or in a shortcut. Also read:
http://blogs.msdn.com/ie/archive/2009/06/06/session-cookies-sessionstorage-and-ie8.aspx
http://www.google.com/search?q=+"session+id"++collision++cookie
The problem noted above involves session ID collisions when using cookies to
identify the sessions. The following regarding the use of an instance-id in
the URL is from Daniel Crichton (with some rephrashing). Rather than use a
session ID in a cookie or in the URL, you could include an "instance id" and
use this to differentiate between the multiple concurrent logins to the same
web application. For example, assume you're using IIS and ASP/ASP.NET
sessions (which uses a known named cookie to identify to the server as to
which session is linked to a server-side object that holds the session
collection information), you would use the instance-id plus the session-id;
however, that requires changing the entire session handling system in your
server code since it has to take into account the inclusion of an
instance-id. For example:
Session("username")
would become:
Session("username_" & instanceid)
where instance-id is the value passed in the URL.
The session ID collisions are a problem for web applications that permit
multiple concurrent connections by the same user. While this may be a
convenience to the user, the server cannot differentiate the sessions unless
a new instance of the web browser is used (that then manages its own session
IDs). Unless a further means is incorporated into the server code to
differentiate between separate but concurrent multiple logins, the server
should not permit multiple concurrent connections from the same IP to the
web application. That is, only one connection per IP address would be
allowed.
Many servers impose a limit (of one) regarding concurrent connections by the
same IP address to eliminate the possibility of session ID collisions or for
security concerns (like spoofing/intercepting a login session). If you open
another tab or child window, the server may assume you simply wanted to use
the same session over there, or it may reject another connection attempt.
For example, some e-mail providers allow a login from only one instance of
an IP address. You cannot login using their webmail interface and also poll
the same account using a local e-mail client while doing both from the same
host.
