Bug in forms authentication?

[mircu]

Hi,
I noticed weird behaviour with the site that is using forms
authentication. I am logged to the site from the same machine from two
browsers (opened separately, not ctrl-N) as different users so two
sessions are created. Then from the one window I logoff but I'm
automatically logouted also from the other browser window. Why?

It is strange that it is working OK if I'm doing it on the same machine
where the web server is located.

regards,
mircu

[Peter Rilling]

If you did a ctrl-N, then they are part of the same session and I would
imaging so is the user logged in.

"mircu" <mi***@op.pl> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...

Hi,
I noticed weird behaviour with the site that is using forms
authentication. I am logged to the site from the same machine from two
browsers (opened separately, not ctrl-N) as different users so two
sessions are created. Then from the one window I logoff but I'm
automatically logouted also from the other browser window. Why?

It is strange that it is working OK if I'm doing it on the same machine
where the web server is located.

regards,
mircu

[mircu]

Peter Rilling wrote:

If you did a ctrl-N, then they are part of the same session and I would
imaging so is the user logged in.

A noted in my post that the other browser window was _not_ opened with
ctrl-N. I know that then it would be the same session.

regards,
mircu

[KMA]

Maybe I'm being thick, but what have sessions to do with forms
authentication. Isn't the auth token saved as a cookie. And the cookie is
shared.

Try using two different browsers rather than two instances of the same
browser type.

BTW, isn't the displayed functionality the desired case? That users remain
logged in at the server even if their browser is restarted/doubly launched.

As stated above, I could be a bit thick.
"mircu" <mi***@op.pl> wrote in message
news:OE**************@TK2MSFTNGP12.phx.gbl...

Peter Rilling wrote:

If you did a ctrl-N, then they are part of the same session and I would
imaging so is the user logged in.

A noted in my post that the other browser window was _not_ opened with
ctrl-N. I know that then it would be the same session.

regards,
mircu

[mircu]

KMA wrote:

Maybe I'm being thick, but what have sessions to do with forms
authentication. Isn't the auth token saved as a cookie. And the cookie is
shared. You are right that sessions and form authentication are separated
things. In my application I have tied it together a little. When the
user is logging I create the auth cookie and add to the response. When
logging out the FormsAuthentication.SignOut() and Session.Abandon() are
called.

Try using two different browsers rather than two instances of the same
browser type.
OK. I've checked this: when I'm connecting from two IE browsers it _is
not OK_, when from two Firefox browsers also _not OK_, but when from one
IE and one Firefox it _is OK_.
Hmm, maybe the auth cookie is shared across the browsers (the same type).
BTW Is there a way to list all cookies stored in memory?

BTW, isn't the displayed functionality the desired case? That users remain
logged in at the server even if their browser is restarted/doubly launched.
When the server is restarted sessions are lost (I have to use in-proc
sessions) so users can not continue work after the server is restarted
and should login again.

As stated above, I could be a bit thick.
"mircu" <mi***@op.pl> wrote in message
news:OE**************@TK2MSFTNGP12.phx.gbl...

Peter Rilling wrote:

If you did a ctrl-N, then they are part of the same session and I would
imaging so is the user logged in.

A noted in my post that the other browser window was _not_ opened with
ctrl-N. I know that then it would be the same session.

regards,
mircu

regards,
mircu

[KMA]

Mircu,

I'm still a bit puzzled as to why you think the observed behaviour is
incorrect. If I launch two instances of the same browser then they share the
same (client-side stored) cookie. If I log on in one then I'm effectively
logged on in the other. The "browser type cookie is logged on", you might
say.

When the server is restarted sessions are lost (I have to use in-proc
sessions) so users can not continue work after the server is restarted
and should login again.

But this is true regardless of how many client browsers are open. In-proc
storage on the server side is held only as long as the server process
exists. But the client side cookie may still be valid and authenticated.
This is also the desirted model, is it not? If I'm logged in to Amazon and
I'm taking 10 minutes to decide whther to buy a book, during which time
Amazon servers restart, why should I be prompted to log in again?

However, if you are personally storing something in a session volatile way
and the sessions are lost through a restart, it is up to you to write that
data to pernanent storage beforehand and recover it after. But I don't see
how the Forms authentication model is to blame here.

KMA

"mircu" <mi***@op.pl> wrote in message
news:uj**************@TK2MSFTNGP12.phx.gbl... KMA wrote:

Maybe I'm being thick, but what have sessions to do with forms
authentication. Isn't the auth token saved as a cookie. And the cookie is shared. You are right that sessions and form authentication are separated
things. In my application I have tied it together a little. When the
user is logging I create the auth cookie and add to the response. When
logging out the FormsAuthentication.SignOut() and Session.Abandon() are
called.

Try using two different browsers rather than two instances of the same
browser type.

OK. I've checked this: when I'm connecting from two IE browsers it _is
not OK_, when from two Firefox browsers also _not OK_, but when from one
IE and one Firefox it _is OK_.
Hmm, maybe the auth cookie is shared across the browsers (the same type).
BTW Is there a way to list all cookies stored in memory?

BTW, isn't the displayed functionality the desired case? That users remain logged in at the server even if their browser is restarted/doubly

launched.
When the server is restarted sessions are lost (I have to use in-proc
sessions) so users can not continue work after the server is restarted
and should login again.

As stated above, I could be a bit thick.
"mircu" <mi***@op.pl> wrote in message
news:OE**************@TK2MSFTNGP12.phx.gbl...

Peter Rilling wrote:

If you did a ctrl-N, then they are part of the same session and I would
imaging so is the user logged in.

A noted in my post that the other browser window was _not_ opened with
ctrl-N. I know that then it would be the same session.

regards,
mircu

regards,
mircu

[mircu]

KMA wrote:

I'm still a bit puzzled as to why you think the observed behaviour is
incorrect. If I launch two instances of the same browser then they share the
same (client-side stored) cookie. If I log on in one then I'm effectively
logged on in the other. The "browser type cookie is logged on", you might
say.
I know that this behaviour can be correct in one situation but it is not
correct in another. In my situation I'd like to log in in one browser
with different role than in another. If I'm logged in one browser, then
if I am automatically authorized to the site from other browsers I can
not log in as a different user with different role.

However, if you are personally storing something in a session volatile way
and the sessions are lost through a restart, it is up to you to write that
data to pernanent storage beforehand and recover it after. But I don't see
how the Forms authentication model is to blame here.

I blame it that it doesn't work in the situation I described earlier. I
agree that in one situation the behaviour is correct but if I wanted
something other it seems that it can't be customized. The fix would be
simple, the cookie name or data should be allowed to append user defined
data (eg. user name/role/id) and then if I wanted to log in from two
browsers I would have two cookies and when logging off only one cookie
(matched the defined data) should be deleted.

regards,
mircu

[KMA]

Mircu,

I think it's true to say that logging in simultaneously with two different
sets of credentials is an exotic requirement, and hence it isn't the default
behaviour of forms authentication. As far as I can imagine, the only reason
to do this is for testing a site. You could do this by lauching multiple
browser types. If you really want to use the same browser, or your users
need to then you're going to have to handroll some extra authentication
code. Either way, I think the plain vanilla forms auth gives you incredible
functionality for the 20 or so lines it take to implement.

KMA
"mircu" <mi***@op.pl> wrote in message
news:#N**************@TK2MSFTNGP09.phx.gbl...

KMA wrote:

I'm still a bit puzzled as to why you think the observed behaviour is
incorrect. If I launch two instances of the same browser then they share the same (client-side stored) cookie. If I log on in one then I'm effectively logged on in the other. The "browser type cookie is logged on", you might say.

I know that this behaviour can be correct in one situation but it is not
correct in another. In my situation I'd like to log in in one browser
with different role than in another. If I'm logged in one browser, then
if I am automatically authorized to the site from other browsers I can
not log in as a different user with different role.

However, if you are personally storing something in a session volatile way and the sessions are lost through a restart, it is up to you to write that data to pernanent storage beforehand and recover it after. But I don't see how the Forms authentication model is to blame here.

I blame it that it doesn't work in the situation I described earlier. I
agree that in one situation the behaviour is correct but if I wanted
something other it seems that it can't be customized. The fix would be
simple, the cookie name or data should be allowed to append user defined
data (eg. user name/role/id) and then if I wanted to log in from two
browsers I would have two cookies and when logging off only one cookie
(matched the defined data) should be deleted.

regards,
mircu