Framework bug with Auth and Session state?

[Jim Johnson]

Dan,
I don't know if it is a bug or not, but I experience the same problems.
Like you say, it is a duplication of effort and annoying when using Visual
Studio.Net.

In my particular case, I was storing a password in a session variable so
that it could be passed each time a connection was made to the database. My
question (which I posted, but received no response) was whether
authenticating using Forms Auth and using a trusted db connection was
sufficient security. In other words: is restricting access to .aspx pages
which access the database sufficient security, or should I use a combination
of Forms Auth and password in the connection string (stored in a session
var)?

If the latter, well, either I put up with the duplication and mismatched
expiration, or I return to my old methods under classic ASP.

Any thoughts?

Josh

<DanR@REMOVETHISTOGETTOME-warshawgroup.com> wrote in message
news:%23GjCNLJRDHA.3144@tk2msftngp13.phx.gbl...

> I posted this under another thread but want to clearly articulate it to

the

> newsgroup.
>
> At the point my user authenticates/logs in, I set up their session

variables

> and use Forms Auth to let them get around the site. I rely on a
> "User.Identity.IsAuthenticated" to tell me if the user is good- by good I
> mean that I assume that if the user is Authenticated that the the session

is

> still valid. The bug is that sometimes the session ends but
> "User.Identity.IsAuthenticated" still returns true.
>
> The problem is that sometimes the user at the browser is in this
> inconsistant state state where the Session has been voided/invalidated

(it's

> empty) but the ASP framework still treats the user as authenticated. This

is

> bad. I'm not sure why the framework treats them as independently managed
> cookies. (I mean I know why it is two different cookies, but not why they
> are not tied together better/more correct/useful way. You can tell me this
> behavior is a feature and not a bug, but I'll reply that it makes it
> somewhat useless.
>
> I specifically see this problem when I am working in the development
> environment- the session gets killed by restarting the debugger, but the
> client/web is still authenticated/signed in.
>
> Obviously I want those things tied together. If I have to do a check on
> every page to see if the session is valid and have them sent to a login

page

> to log in if it is not valid- well, guess what? I've just rebuilt the

Forms

> Auth functionality of the following config and having it available to me

is

> not useful.
>
> <authorization>
> <deny users ="?" />
> <allow users ="*" />
> </authorization>
>
>

[andrew]

<DanR@REMOVETHISTOGETTOME-warshawgroup.com> wrote in message
news:%23GjCNLJRDHA.3144@tk2msftngp13.phx.gbl...

> I specifically see this problem when I am working in the development
> environment- the session gets killed by restarting the debugger, but the
> client/web is still authenticated/signed in.

Dan,

If your session state is set to InProc you'll see this behaviour, however if
you use StateServer or SqlServer session state modes, the session will not
be reset when recompiling your dll's.

hth
andrew

[Joe Iano]

I don't think it's a bug. The user's authentication is maintained by a
cookie on the client's browser. So as long the browser stays open, the
cookie remains, and the user is authenticated. I am guessing that since the
user's credentials are stored in the cookie itself, and not on the server,
the authentication never times out.

Session info is stored on the server, using the session cookie only as an
id. So when an inactive session is dropped, the session information is lost.

Perhaps in your case, you would be better off checking for a valid session,
rather than "User.Identity.IsAuthenticated". If the use isn't authenticated,
they shouldn't show up at all in, so that's not really telling you much. But
if you find a user with no session (and also authenticated), then you will
need to re-establish their session status, whatever that entails for your
application.

<DanR@REMOVETHISTOGETTOME-warshawgroup.com> wrote in message
news:%23GjCNLJRDHA.3144@tk2msftngp13.phx.gbl...
I posted this under another thread but want to clearly articulate it to the
newsgroup.

At the point my user authenticates/logs in, I set up their session variables
and use Forms Auth to let them get around the site. I rely on a
"User.Identity.IsAuthenticated" to tell me if the user is good- by good I
mean that I assume that if the user is Authenticated that the the session is
still valid. The bug is that sometimes the session ends but
"User.Identity.IsAuthenticated" still returns true.

The problem is that sometimes the user at the browser is in this
inconsistant state state where the Session has been voided/invalidated (it's
empty) but the ASP framework still treats the user as authenticated. This is
bad. I'm not sure why the framework treats them as independently managed
cookies. (I mean I know why it is two different cookies, but not why they
are not tied together better/more correct/useful way. You can tell me this
behavior is a feature and not a bug, but I'll reply that it makes it
somewhat useless.

I specifically see this problem when I am working in the development
environment- the session gets killed by restarting the debugger, but the
client/web is still authenticated/signed in.

Obviously I want those things tied together. If I have to do a check on
every page to see if the session is valid and have them sent to a login page
to log in if it is not valid- well, guess what? I've just rebuilt the Forms
Auth functionality of the following config and having it available to me is
not useful.

<authorization>
<deny users ="?" />
<allow users ="*" />
</authorization>

[Teemu Keiski]

You could try to reduce the problem by having same timeout on both (30
minutes for session and 30 for forms auth), although it won't solve it
because user might have had session going for how long and he/she has not
yet authenticated (depends on the app and user). Or then just make session
timeout bit greater than Forms Auth timeout.

And also if possible call Session.Abandon right when user is authenticated
so that they (auth and session) would start somewhat same time.(it will of
course abandon the session but then start a new one as well)

--
Teemu Keiski
MCP,Designer/Developer
Mansoft tietotekniikka Oy
[url]http://www.mansoft.fi[/url]

ASP.NET Forums Moderator, [url]www.asp.net[/url]
AspAlliance Columnist, [url]www.aspalliance.com[/url]

Email:
[email]joteke@aspalliance.com[/email]


<DanR@REMOVETHISTOGETTOME-warshawgroup.com> kirjoitti viestissä
news:%23GjCNLJRDHA.3144@tk2msftngp13.phx.gbl...

> I posted this under another thread but want to clearly articulate it to

the

> newsgroup.
>
> At the point my user authenticates/logs in, I set up their session

variables

> and use Forms Auth to let them get around the site. I rely on a
> "User.Identity.IsAuthenticated" to tell me if the user is good- by good I
> mean that I assume that if the user is Authenticated that the the session

is

> still valid. The bug is that sometimes the session ends but
> "User.Identity.IsAuthenticated" still returns true.
>
> The problem is that sometimes the user at the browser is in this
> inconsistant state state where the Session has been voided/invalidated

(it's

> empty) but the ASP framework still treats the user as authenticated. This

is

> bad. I'm not sure why the framework treats them as independently managed
> cookies. (I mean I know why it is two different cookies, but not why they
> are not tied together better/more correct/useful way. You can tell me this
> behavior is a feature and not a bug, but I'll reply that it makes it
> somewhat useless.
>
> I specifically see this problem when I am working in the development
> environment- the session gets killed by restarting the debugger, but the
> client/web is still authenticated/signed in.
>
> Obviously I want those things tied together. If I have to do a check on
> every page to see if the session is valid and have them sent to a login

page

> to log in if it is not valid- well, guess what? I've just rebuilt the

Forms

> Auth functionality of the following config and having it available to me

is

> not useful.
>
> <authorization>
> <deny users ="?" />
> <allow users ="*" />
> </authorization>
>
>

[Colin Turner]

I have found the same problem. I got around it by storing an encrypted
forms authentication ticket into the cookie as described in Microsoft's book
Building Secure Microsoft ASP.NET Applications.

Public Sub Login(ByVal emailAddress As String, _
ByVal password As String, _
Optional ByVal newAccount As Boolean = False)

Dim account As New Account
Dim accountInfo As AccountInfo

' Do the login through the business layer
accountInfo = account.Login(emailAddress, password)

' Set the account info into session variable
HttpContext.Current.Session(sessionAccount) = accountInfo

' Create the authentication ticket
Dim authTicket As New FormsAuthenticationTicket(1, _

accountInfo.webUser.emailAddress, _
DateTime.Now, _

DateTime.Now.AddMinutes(5), _
False, _
String.Empty, _

FormsAuthentication.FormsCookiePath)

' Encrypt it and put in forms auth cookie
Dim encryptedTicket As String =
FormsAuthentication.Encrypt(authTicket)
Dim authCookie As HttpCookie = New
HttpCookie(FormsAuthentication.FormsCookieName, _
encryptedTicket)
HttpContext.Current.Response.Cookies.Add(authCooki e)

' Redirect to our original location

HttpContext.Current.Response.Redirect(FormsAuthent ication.GetRedirectUrl(acc
ountInfo.webUser.emailAddress, False))

End Sub

Then in global.asax, I check the expired flag of the ticket and if it has
expired, force another login. I haven't managed to make it a little more
selective yet and only force a login when a page that requires an
authenticated user is viewed !!!

Sub FormsAuthentication_OnAuthenticate(ByVal sender As Object, ByVal e
As FormsAuthenticationEventArgs)
' Fires upon attempting to authenticate the user

' Get the cookie
Dim cookieName As String = FormsAuthentication.FormsCookieName
Dim authCookie As HttpCookie = Context.Request.Cookies(cookieName)

' Is there an auth cookie
If authCookie Is Nothing Then
Return
End If

' Attempt to decrypt the ticket
Dim authTicket As FormsAuthenticationTicket = Nothing
Try
authTicket = FormsAuthentication.Decrypt(authCookie.Value)
Catch ex As Exception
Return
End Try

' Ticket did not decrypt
If authTicket Is Nothing Then
Return
End If

' Has the auth ticket expired
If authTicket.Expired() Then
' Force a sign out
FormsAuthentication.SignOut()
Return
End If

' Create the authentication ticket
Dim formsID As New FormsIdentity(authTicket)

' Attach the identity to the principal
Dim principal As GenericPrincipal = New GenericPrincipal(formsID,
Nothing)
Context.User = principal

End Sub


Regards
Colin

<DanR@REMOVETHISTOGETTOME-warshawgroup.com> wrote in message
news:%23GjCNLJRDHA.3144@tk2msftngp13.phx.gbl...

> I posted this under another thread but want to clearly articulate it to

the

> newsgroup.
>
> At the point my user authenticates/logs in, I set up their session

variables

> and use Forms Auth to let them get around the site. I rely on a
> "User.Identity.IsAuthenticated" to tell me if the user is good- by good I
> mean that I assume that if the user is Authenticated that the the session

is

> still valid. The bug is that sometimes the session ends but
> "User.Identity.IsAuthenticated" still returns true.
>
> The problem is that sometimes the user at the browser is in this
> inconsistant state state where the Session has been voided/invalidated

(it's

> empty) but the ASP framework still treats the user as authenticated. This

is

> bad. I'm not sure why the framework treats them as independently managed
> cookies. (I mean I know why it is two different cookies, but not why they
> are not tied together better/more correct/useful way. You can tell me this
> behavior is a feature and not a bug, but I'll reply that it makes it
> somewhat useless.
>
> I specifically see this problem when I am working in the development
> environment- the session gets killed by restarting the debugger, but the
> client/web is still authenticated/signed in.
>
> Obviously I want those things tied together. If I have to do a check on
> every page to see if the session is valid and have them sent to a login

page

> to log in if it is not valid- well, guess what? I've just rebuilt the

Forms

> Auth functionality of the following config and having it available to me

is

> not useful.
>
> <authorization>
> <deny users ="?" />
> <allow users ="*" />
> </authorization>
>
>