:D
but does it clear up your understanding of why you cant redirect in session_end ?
Printable View
:D
but does it clear up your understanding of why you cant redirect in session_end ?
Yes it does, thanks for the info. My only lingering question is why isn't an unhandled exception raised when you try to do something with Response in Session_End? I guess I would imagine one would generate an exception, and not just have the code die.
Well, like I was alluding to before, the session timeout will occur regardless if the client is even connected to your site. So it would make sense that there probably would not be a Response object available to redirect.Quote:
Originally Posted by Mike Hildner
Your problem is more you need a way to authenticate people... that ties into asp.net (forms authentication for example)... and then you don't have to worry about session timeout, because for your app, it probably makes little difference. At worst, the user will have to re-authenticate if they don't touch anything in 20 minutes.
There's a multitude of ways of handling session.. cookieless or with cookies, sliding expiration or not, or even setting session timeout in the future. You could store the session data itself inside a cookie the client passes, thereby eliminating the need to store it on the server. But all of that above really depends on what the expected load(number of users) of the server is, and how content it has to pour down the pipe.
In a forms app I was making, I built this subroutine
Perhaps you can put it to good use if you implement
forms authentication.
Code:Private Sub Global_AcquireRequestState(ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.AcquireRequestState
If Request.IsAuthenticated Then
Try
If Session("userguid") Is Nothing Then
'we have an authenticated user
'with no current session
'so lets do this
'let's remove their authentication ticket
'then redirect them to logon.aspx
FormsAuthentication.SignOut()
Response.Redirect("logon.aspx")
End if
Catch ex as exception
End Try
End If
End Sub
Thanks for the info, nemoroller. Let me ask then, is forms authentication the way to go? I've read up on the different methods, just wondering for a real-life app is that's standard practice.
I'm guessing the answer depends on your needs, but I'm so new to this, I don't think I'm the one to judge.
FWIW, the only reason I care about the session timing out and redirecting is because that's a contractual requirement. That is, if the user walks away from their machine, they'll need to re-authenticate after x minutes. Right now, any authenticated user would be authorized for anything, but I'm sure that will change.
Oh, and I'd like to go cookie-less if that's possible, just so I can thwart any opposition, even if that opposition doesn't make sense.
Additional information you may not care about: This application will serving up information on arrested individuals, and there's state and federal guidelines I must follow (I'm in the USA). Hence the need for some pretty decent security.
Thanks,
Mike
Well,
Windows Authentication is the most secure mode of authentication available in asp.net authentication schemes.
However, it does not work on non-windows machines or machines that are not part of the same domain (or at least would be able to access a list of accounts and their permissions from say active directory services).. its geared toward intranet, which excludes internet use. I assume that may not be problem for you however.
Forms authentication is THE ONLY secure method available for crossing domains and different platforms. Forms Authentication is rather prevalent now in asp.net applications that cross the intranet barrier to the external world. For my part, I coupled Forms with a SSL layer, so usernames and passwords could not be inspected (at least easily anyway).
Most government agencies require Triple-DES encryption, which I believe at minimum is 128bit security. You will want to encrypt your database connection strings no matter where you store them (web.config or registry, or even a flat file).. http://msdn.microsoft.com/library/de...classtopic.asp
With all that said however, Forms and Windows Authentication can be combined, so some aspects of site can still be accessible to a user even if they are not directly connected to the internal network. Of course, VPN is also a good solution to allow workers to access internal networks, in which case Windows Authentication works flawlessly.
Another aspect to consider is securing highly confidential or sensitive data in a subdirectory, secured by its own web.config with its own authentication (so you could have Forms for the initial welcome page, and browsing newsletters or such, and when the user needs to access privy data, they will need to supply their Windows user account to access that data).
In the mean time, the subroutine I listed below is part of a forms authentication implementation, which would log the user out when their session expired - because a client browser could still have a valid authentication ticket - of course that also depends on how long you state that authentication is valid). So that would solve your need to de-authenticate a user after x amount of minutes.
And there are a lot of places security wise that will need to be double-checked as a safeguard. For instance, just because a HTTPRequest posts data to your web application, it does not mean it hasn't been maliciously altered by a third party deflecting the communication. This is where SSL is handy. And of course you know about always validating input fields on the server side even if you do implement client-side validation.
For you right now, the thing to remember is session and authentication are really two seperate independent mechanisms. You should just google for 'Forms Authentication asp.net', or even search some threads here, I'm sure myself and others have given examples of how to implement it.
two parts really to a forms authentication scheme...
1) The web config part
This goes inside of the <system.web></system.web> tags in your web.config
Code:<!-- AUTHENTICATION
"Forms" You provide a custom form (Web page) for users to enter their credentials, and then
you authenticate them in your application. A user credential token is stored in a cookie.
Protection tag encrypts and validates the authentication cookie
-->
<authentication mode="Forms">
<forms loginUrl="logon.aspx" protection="All" name="AuthCookie" timeout="22" path="/">
</forms>
</authentication>
<!-- AUTHORIZATION
This section sets the authorization policies of the application. You can allow or deny access
to application resources by user or role. Wildcards: "*" mean everyone, "?" means anonymous
(unauthenticated) users.
-->
<authorization>
<deny users="?" />
<allow users="*" />
</authorization>
2) Adding the authentication ticket
here's an example of how to attach an authentication using forms in a login page.... (logon.aspx)
Code:'grab the username and passwords from textbox fields, ask
'database if supplied username and password are valid
'if database recognized the supplied login as valid, authorize user
Dim authTicket As FormsAuthenticationTicket = _
New FormsAuthenticationTicket(1, userguid, DateTime.Now, DateTime.Now.AddMinutes(22), False, "")
'encrypt ticket
Dim encryptedTicket As String = FormsAuthentication.Encrypt(authTicket)
'create a cookie and add the encrypted ticket to the cookie as data
Dim authcookie As HttpCookie = New HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket)
'add cookie to outgoing cookies collection
Response.Cookies.Add(authcookie)
'redirect user to default page
'go where you want to go
Response.Redirect(FormsAuthentication.GetRedirectUrl(userguid, False))
'if auth failed, don't do a thing, just let the page re-render
Wow, cool. Thanks for all that info. Will be reading up on forms authentication. I'm in control of all the hardware, network etc., so I guess I could use Windows authentication as well. Time to do some reading.
Again, thanks for the information.
because its pants and it should do :DQuote:
Originally Posted by Mike Hildner