I am trying to set Session values using a IHttpModule. I have set the HttpModule to be used for all requests, not just managed/ASPX pages.
I found however, that when a request for a non-ASP.NET page came in (such as gif) the Session member of the HttpApplication would throw an exception or be null.
I found the following SO post for the reason behind this: link
When I am swapping out the HttpHandler with one that implements IRequiresSessionState the Session member is available in the HttpModule, and a Set-Cookie is sent back to the browser, but later when I try to read the contents of the session in a normal ASPX page none of the values I set are there. When debugging I can see that the SessionID is the same in both the HttpModule and normal ASPX page.
Do I need to do anything to force the session to be saved? I am assuming that while swapping in the fake HttpHandler initialises the Session, having to put the original which doesn't implement IRequiresSessionState back in causes the session to not be saved at the end of the request.
I just worked it out, I had to move the re-mapping of the original HttpHandler from PostAcquireRequestState to PreRequestHandlerExecute.
Related
I have to implement session handling across multiple users, and multiple browsers. Each user has a unique token which I save in HttpContext.Current.Session variable inside the Session__Start() in Global.asax.cs method. It works perfectly fine for a single session. However, when I fire the request from two browsers, then while browsing through various pages, sometimes the method Session_Start() automatically gets called for the second session and it resets the session variable, resulting in a null value.
How should I handle this scenario?
Edit 1:
What are the scenarios where the session may time out? Eg: switching between HTTPGet/HttpPost, or making Ajax calls?
I also read this link:
Does Session timeout reset on every request
Is this something which I should be keeping in mind? My code has 2 GET and 1 POST request, and the session variable becomes NULL in the POST method for the second browser session.
I figured out the reason. The sessionState mode in web.config file was set to "InProc", whereas it should be set as "StateServer". When I made the necessary change, then it worked like a charm.
ASP.net state service should also be started from services.msc for this to work.
I have Serialize all class from which I am adding object parameter in session and all session value are storing except which is not in aspx.cs page. after that Redirecting aspx page to some other page but it is throwing error when I have done throwOnError="false" in web.config page it is not throwing error but its session value is not coming and afterword it is not storing any session value in to the application.
Any suggestion is welcome
The official answer from Microsoft:
Unfortunately HttpWebRequest dropped
support for serialization after .NET 1.1. See
http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.httpwebrequest(v=VS.100).aspx
We’ll see if we can get that attribute removed to avoid this confusion
in the future.
They changed the documentation to include the [ObsoleteAttribute] attribute.
I have inherited textbox and dropdownlist controls in C# and added some custom logic to them for setting background and all in C#
I am adding them to my user control(ascx) and using this usercontrol in aspx page. But On postback I lose values for all textboxes dropdown etc.
Can anyone help.
That's just the way it works, and it's worse than you think. It's not that your control is losing it's data. It's that it's not even same instance of the control any more.
In ASP.Net, you work with a completely new instance of your page class, including any controls in the class, on every postback. There is a page lifecycle you need to understand before you'll be able to do much, but the summary goes like this:
User sends an http request for a page via the browser
ASP.Net runtime in IIS creates an instance of the page and calls methods like Pre_Init, Load, Render, etc in a specific order.
The result of this process is then used to send an http response to the user's browser with the rendered html.
Once the response is sent, the page class instance is disposed and destroyed. It no longer exists.
The browser receives the http response and renders the page for the user.
If the user does anything that causes a postback, the entire process starts again. It's a whole new http request, a whole new page class, and a whole new http response. Things like calling the page's Load method are repeated. Also note the order for steps 4 and 5. Due to latency between the browser and web server, it's common that the page class is already destroyed before the response even reaches the user. By the time the user sees a page, the class instance that produced the page is already long gone.
To get around this, you need to put data that should persist across requests into a storage location that will actually persist, such as ViewState or the Session.
This question might be ridiculous, sorry for that.
Which event is best for reading session data - Page_Load or Page_Init event?
Currently I am using Page_Load event for such tasks. But i have seen in an article to do in Page_Init event.
Thanks.
Update: http://csharpdotnetfreak.blogspot.com/2008/11/detecting-session-timeout-and-redirect.html
It doesn't matter, use the event where you need it. A Session variable is stored in server memory(by default), so it doesn't depend on the current page's lifecycle.
http://msdn.microsoft.com/en-us/library/ms178581.aspx
Session is attached with your request while http request passes through ASP.NET pipeline. So before the page processing begins, you have your session with you. Session is stored on the server and is attached to your user request with the help of session id cookie. This cookie identifies each unique request and attaches session data(Session Module does this work).
I think you are confused with ViewState, because ViewState is stored and read in page life cycle (LoadViewState and SaveViewState event)
Also the article that you have pointed is for detecting new sesssions and time outs. It makes sense to do all the checking in Page_Int, so that response is sent as early as possible
You can access the the session data at any any stage of the page lifecycle. It does not affect it in any way. There is nothing like the 'best' or the 'worst'.
Be more consistent. If your request need some kind of INFORMATION (no matter where you store it), then you should check the presence of INFORMATION before excuting the request.
If you store your information in sesssion than use:
Global.asax:Application_BeginRequest
this prevent you from copy-paste single requirement to multiple page.aspx
Recently I have been asked by a client to log into a legacy site using POST and not GET (from a 3rd party site), All of the needed variables are now sent within a post instead of a query string.
The problem is that upon receiving all of variables they are stored into Session and then redirected to the correct page within the application (from the logo-in Page).
While this works perfectly while calling the page using GET, a POST call will lose all of the Session variables after
Response.Redirect(#"~/SOMEPAGE.aspx",false);
Another thing that is odd is that the Session ID will remain the same but all values will be gone.
When Using Server.Transfer the session is intact but will be lost once the Response.Redirect is used. (there is no option to change all of the code.)
Does any one know of a way to resolve this or some sort of a work around that might be used.
Thanks!!!
There are a few reasons this could happen.
You are using Session.Abandon() in your code
You are switching between a secure (https://) and insecure (http://) URL
You have some code in your global.asax that is manipulating Session, or the .Secure or .Path properties of your Response.Cookie
edit http://forums.asp.net/t/1670844.aspx