Session invalidation means session destroying.So if session is destroyed,it indicates that server cant identify the client which has visited in previous.So now it creates a new session id for that client.
Is this right?If wrong tell me the correct procedure.
Calling HttpSession.invalidate() simply clears any object that is bound to it and marks it as invalid, so if you try to modify it afterward it will throw exceptions.
Once a session has been invalidated, the SessionID placed in a cookie on the client will be invalid too, and a new one will have to be created when a new session object is created. So the new Session will have a new ID.
This is usefull to handle for example login/logout. Sessions should always be invalidated at login to help prevent Session fixation attacks
Yes, absolutely right. Invalidating a session will mark the session as invalid and will be destroyed. If the client comes with the session id which has been invalidated a new session will be created.
session.inValidate():
If we are logging into gmail then at server side server will create session object
If we are calling session.inValidate() method means we are logged out since session object is destroyed by the server.
Related
When I store a value in a session and some exception occurs afterwards, the session state might not be persisted.
Session["MyKey"] = value;
throw new Exception("Test exception");
I found out that if I'm using InProc mode, the value gets persisted immediately, so if an exception occurs, it's stored anyway.
But if I switch to StateServer mode, the value will not get persisted if an exception occurs. I can write to the session, read it again from the session, but after an exception occurs, it's like all the changes I made to the session state in that request will be discarded (i.e. not persisted). And any future request will read the "old" state of the session.
At first I was thinking that it's related to the session cookie not being sent in response in case of the exception, but this behavior occurs for sessions that already exist and users already hold their identifiers. It also clearly differs from InProc to StateServer, while both of these approaches handle cookies the same way, it's just the persistance layer that is different.
How does the session state persistance work? At which point in the request lifecycle are the changes actually persisted to StateServer? Is it possible to force persisting of the session state, so it would be persisted even after an exception occurs?
The docs says
https://msdn.microsoft.com/en-us/library/system.web.httpapplication.releaserequeststate.aspx
HttpApplication.ReleaseRequestState Event. Occurs after ASP.NET finishes executing all request event handlers. This event causes state modules to save the current state data.
I am learning Servlet. But don't understand the major difference between HttpSession object and HttpContext object ? As both are used to keep track of the user. But I don't understand , are both of them being accessible across the user or servlet ?
Can anyone provide me an example for this, so I can have clear understanding of it...
Request - Normally used for passing data from jsp to your servlet when you submit the form. When you get redirected to another jsp, your request dies. ie: this attribute lives per user request.please note that http is stateless protocol.so the server will treat every http request as a new request.
Session -session object is basically used to store the values in the session.the data will be preserved until the user terminates the program or closes the browser.Good example will be for storing user credentials. once user is authenticated, Sometimes you may want to check if the user has right access to do on some database operations like add/delete/edit. Once user closes the browser or the session goes idle for x amount minutes (depending on your server setup), the session dies and all info in it will be gone.
Context -context object can be used for multiple users and across multiple browsers.
If it is application specific, consider using context.
If it is user specific, consider using session.
If it is request specific (ex: jsp form submission), consider using request.
Hope this helps.
I want to run some database processing when a user's session expires, but I need to know what user it was whose session expired.
I was considering simply setting the Session["CurrentUserId"] upon login which could then be accessed when the session expires, but thought there might be a way of getting the HttpContext.User.Identity directly from the Session?
Well, looking at the class definition on MSDN, it doesn't looks like you can access it right from a Session's property / member.
However, They are both properties of the same object, which in your case is going to be the current HttpContext. So when the session ends for one context (understand : one http request), the current user of the context is the same as the one you are looking for.
Otherwise, you could always use a hashtable stored in cache where the key would be the Session.SessionId and the value would be the User identity.
During Session Start, one has access to the Request object. How about Session End, does it still have access to the Request object ? For example I want to count how many browsers are currently connected to my application.
Edit 1 : If Session End doesn't have access to Request Object, what info does it have access to ? Session ID, etc ?
Edit 2 : If Session End cannot be used to track disconnections, how does one track disconnections in ASP.Net ?
Thanks
No, the Request object is not available in Session End.
Note too that Session End only fires when you call Session.Abandon() from code, not when a Session expires due to natural timeout or what-have-you. Consequently, it is not a reliable method to use for tracking disconnections.
Session_End will be fired if one is using InProc.
Session_End will be fired
1) after n minutes of inactivity (n = timeout value), or
2) if someone calls Session.Abandon()
Session_End doesn't get fired if one closes the browser.
Session_End requires session state to be set.
If one needs the original Request.Browser data, one should save it in Session State.
During Session_End, it has access to the Session State.
from the documentation
The Session_OnEnd event occurs when a
session is abandoned or times out. Of
the Server built-in objects, only the
Application Object, Server Object, and
Session Object objects are available.
Remarks
You cannot call the Server.MapPath
method in the Session_OnEnd script. By
default, Session_OnEnd runs as the
Anonymous User, as defined for the
application. In the event that there
isn't an Anonymous user, or the Logon
for the Anonymous user fails, the
OnEnd function will not be called, and
an event will be logged.
I have a wrapper class for Caching (CachingBL) where I store users that are currently signed in (some of their session info).
In CachingBL wrapper there is actually a dictionary of users, and I am putting that dictionary in cache like this: HttpContext.Current.Cache.Insert(...):
At the session end I would need to access to the cache like this:
var cacheBL = (CacheBL)HttpContext.Current.Cache.Get("MyCache_CacheSlot");
But the problem is that HttpContext.Current is empty, so I cannot access the Cache object. The Cache itself is not empty (tested), but I can't figure out how to access it at Session_End.
You can use System.Web.HttpRuntime.Cache to access the cache statically.
Instead of putting the whole dictionary in the cache as one cache entry, put each element in the cache as an entry. Then you can give each element a sliding time window of the session timeout time, and let the system handle expiration.
Inside the Session_OnEnd event there is no way to get access to the HttpContext.Current because there is no current request.
But you do have access to the session state which includes all session variables. So if you us a session variable to store your token to the key name of the sessions cache slot ("MyCache_CacheSlot" in your example), you will be able to release that cache inside the Session_OnEnd event.
System.Web.SessionState.HttpSessionState is the one I should use instead of HttpContext.Current