Related
I need to share session in order to pass data from asp page to aspx. The solutions I've found:
• Pass data through hidden form (link)
• Pass data through database (link)
I've tried method with form and it worked fine (after some modification). Now I'm trying method with database. First method is easier imho, so I wonder if the second method is more secure (and preferable) than the first one?
And what potential problems exist with these methods?
The first solution is definitely less secure since you're sending session data to the client and then receiving it back. That means that it's possible for someone on the client side to modify the data they post back to your page. This removes one of the best things about sessions, that only the programmer controls what's in them. In a way, the first method is similar to using cookies. As for the second method, it may be more difficult but I would definitely recommend it over the first.
If the session is encrypted I think you will fine. ASP.NET has the option of storing the session in a database and URL querystring to get around users not having cookies enabled. Your solutions sound similiar.
Microsoft outlines a method to share session state between ASP classic and ASP.NET using SQL Server to store the session here: http://msdn.microsoft.com/en-us/library/aa479313.aspx
I'd like to store a few variables which will be referenced throughout lifecycle, starting with a db access in PreInit event. ViewState isn't an option, since it won't persist if saved so early during the page lifecycle. Given that data should not be altered by a user, what would be the best alternative?
You could use the Session to store your data. I am not sure on the number of users of your system, but assuming the data you want to store is small this won't be a problem.'
Also, unless you are using a SessionPageStatePersister (or another server side persister) or encrypting your ViewState it is still possible for the user to change the ViewState. It may be harder, but it is still possible. By default ViewState uses HiddenFieldPageStatePersister and it stores the ViewState in a hidden field on each page (as an encoded string). Just something worth considering.
Depending on the scope: Session or Application
Session
If you want the data stored per user
Application
If you want the data stored available for all users
You could store data in hidden fields, and if you want to obscure it, you could use some kind of encription. Of course these values would also only load in a later stage of the page lifecycle. The session object would be the obvious choice, although it's not everybody's favourite method.
Session probably wouldn't be available at PreInit, but you could store them in variables until a later page lifecycle task, and then store them in session at that time. I could be wrong about the session feature. Additionally, cache is an option but caching is not user-specific; you can make it user specific by appending their user ID or session ID.
Session is probably your best bet. We have to use the session to store some user information, but hit a bug due to accessing it too early. The bug is [HttpException]: Session state has created a session id, but cannot save it because the response was already flushed by the application." But it will often manifest as PageRequestMangerParserErrorException. Super fun hunting that down. One hackish fix is to write into your Global.asax code behind:
public Session_Start(object sender, EventArgs e)
{
string sessionId = Session.SessionID;
}
Accessing the SessionID forces the ASP.NET engine to go build the session before it normally would, making it possible to use it early.
Outside of session (or application) you have two other options: client storage and persistent storage. The latter is a fancy way of saying "stuff it in the database", though similar alternatives exist, of course.
Client Storage is like viewstate, but more controlled. You can use hidden fields or cookies. In fact, a cookie might work out well for you, but you'll need to encrypt the information in it if you want the user to leave it alone. Regardless, anything you send to the client you must assume is compromised, so always do a validity check.
Is there a built-in asp.net way to conditionally serve pages, for example I want the following logic:
If there is a session data I generate
a page, if there is no session data I
serve the cached page.
I am only interested in knowing about a built-in asp.net mechanism for this. If it does not exist I am probably going to simply cache my page manually and decide whether to serve it or not for each request, based on the session data availability.
I don't think there is built-in support (like varyByParam) for generating fresh output for users with Session Data.
As you suggest, I would recommend manually caching the pages. I would probably determine the user's Session state in the PreRequestHandlerExecute event handler in the Global.asax and then maybe set:
HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache);
At the risk of karmabombing, I really don't like this approach to caching.
For me if a GET request is made, then a server should respond to that in good faith. Caching at a page level should be controlled by http headers because the primary goal is not to get the redundant request at all - you don't want to allocate server/bandwidth resources full stop.
Caching objects which are resources involved in making up a page I can totally get behind, but I can't see great arguments for caching a page wholesale.
Respect the headers.
You might want to look at the substitution control (Link) new in .NET 2.0, however it might not be exactly what you are after.
Let's say you have a aspx page that does not rely on session, but does rely on viewstate for persistance between postbacks.
If a user is accessing this page, and leaves for a long lunch, will viewstate still be valid when he returns?
Viewstate itself does not expire. Since it's posted back in a form, it can be reconstituted any time.
According to MSDN: "...it is possible for view state to expire if a page is not posted back within the session expiration time". So, in a round about sort of way, it can expire if your session does, but viewstate does not directly expire. Since you're not using session state anyway, you don't have to worry about implicit expiration.
Note that I wouldn't have said it expired. That was MS who I quoted in their own article entitled Controlling ViewState
No ViewState is kept as part of the PostBack process. You can, however, override the Page class's SavePageStateToPersistenceMedium() and LoadPageStateFromPersistenceMedium(), to implement that behavior if desired. For more information read Understanding the ASP.NET ViewState.
Note that Page ViewState is stored in the Session so if your Session expires, the ViewState will be lost. I wouldn't say this is ViewState expiring, but yes, it will be destroyed after Session timeout.
Also, as a gotcha, by default ASP.NET encrypts ViewState with an autogenerated key. This can be overridden with the MachineKey element in the web.congif file. Even though ViewState won't expire, it can become invalid if a different autogenerated key is used to decrypt ViewState, such as after an IIS Reset, redeploying an application, or hitting a different server in a web farm. If you're planning on storing viewstate for long periods of time, watch out for how it's encrypted/decrypted.
http://msdn.microsoft.com/en-us/library/ms998288.aspx
Viewstate does not expire.
All viewstate data is stored on the client and is submitted back to the server when the user executes a postback.
This has some very interesting implications, and is explained very thoroughly here.
Yes, ViewState expires in certain conditions. For example when you are using iframe:s, or when you are upkeeping "live" connection to the server with regular postbacks. Then you might want to investigate this option: <sessionPageState historySize="9"/>, which actually hard-codes how many "postback results" are stored in the Session (if SessionPageStatePerster is used). Each postback stores it's ViewState to the end of the Queue in Session["__VIEWSTATEQUEUE"], and deletes ViewStates that are "too old". And how do you think SessionPageStatePerster decides which ViewStates are too old.. by configuring some arbitrary historySize-constant in web.config.. Omg! It too me forever to find this problem... My hatred toward asp.net programming is undescribable now.. grrr...
Viewstate does not expire, as long as they are still on the page, it will still be there and functional.
The ViewState will persist from POST to POST. It's actually stored inside a hidden field on your form so that it gets POSTed back to your server all the time.
As long as you aren't relying on the Session you shouldn't have any problems rebuilding page state. It's easy to test your Page's state code if you want though: just set your session to expire after 60 seconds in your web.config then load your page, wait a little more than a minute (surf over to Stack Overflow and answer some questions) and then click a button on your page.
Sorry to relive this old thread, but new information is available now:
Yes, ViewStates expire. I come from 19 hours researching about a problem of ViewStates losing its values between long time interval postbacks. It took me a while reading MSDN documents and Stackoverflow answers saying it was basically impossible to happen unless a custom ViewState storage implementation was employed, which, now I know, it's not true.
My problem was taking place in a SharePoint 2013 environment. The service known as Distributed Cache (a.k.a. AppFabric) does the caching of the ViewState and has a Time to Live associated to it. You can find more information here:
http://blogs.msdn.com/b/besidethepoint/archive/2013/03/27/appfabric-caching-and-sharepoint-1.aspx
The interesting bit of information can be found in this phrase:
"To improve page performance, beginning in SharePoint 2013 SharePoint caches ViewState data server-side rather than transferring it back and forth to clients."
I hope this information helps somebody so desperate as I was 19 hours ago.
ViewState is kept in a hidden field on the page itself. So as long as the user has the page, he'll have the ViewState. But if your app automatically logs the user out after a certain period of time, still having the ViewState may not do him any good.
By default, Viewstate is included with the html content as a hidden input. That means it won't expire, but that everything in viewstate must be uploaded from the user's browser. Since that's typically the slowest part of the connection in a public site, putting a lot of stuff in viewstate can quickly make your site seem very slow.
The short answer is: no.
The longer answer is: it depends on implementation of ViewState storage. You can provide custom implementation of ViewState which could expire after given amount of time. For example, you could store ViewState in database or on disk and send only some reference to the stored value in a hidden field. Then you can use batch processing to remove outdated ViewState data or perform expiration upon request.
No Viewstate doesnot expires.After redirecting to other page then value of view state lost or expire viewstate.
for more detail http://www.c-sharpcorner.com/UploadFile/78d182/Asp-Net-state-management-techniques/
I am wanting to store the "state" of some actions the user is performing in a series of different ASP.Net webforms. What are my choices for persisting state, and what are the pros/cons of each solution?
I have been using Session objects, and using some helper methods to strongly type the objects:
public static Account GetCurrentAccount(HttpSessionState session)
{
return (Account)session[ACCOUNT];
}
public static void SetCurrentAccount(Account obj, HttpSessionState session)
{
session[ACCOUNT] = obj;
}
I have been told by numerous sources that "Session is evil", so that is really the root cause of this question. I want to know what you think "best practice", and why.
There is nothing inherently evil with session state.
There are a couple of things to keep in mind that might bite you though:
If the user presses the browser back button you go back to the previous page but your session state is not reverted. So your CurrentAccount might not be what it originally was on the page.
ASP.NET processes can get recycled by IIS. When that happens you next request will start a new process. If you are using in process session state, the default, it will be gone :-(
Session can also timeout with the same result if the user isn't active for some time. This defaults to 20 minutes so a nice lunch will do it.
Using out of process session state requires all objects stored in session state to be serializable.
If the user opens a second browser window he will expect to have a second and distinct application but the session state is most likely going to be shared between to two. So changing the CurrentAccount in one browser window will do the same in the other.
Your two choices for temporarily storing form data are, first, to store each form's information in session state variable(s) and, second, to pass the form information along using URL parameters. Using Cookies as a potential third option is simply not workable for the simple reason that many of your visitors are likely to have cookies turned off (this doesn't affect session cookies, however). Also, I am assuming by the nature of your question that you do not want to store this information in a database table until it is fully committed.
Using Session variable(s) is the classic solution to this problem but it does suffer from a few drawbacks. Among these are (1) large amounts of data can use up server RAM if you are using inproc session management, (2) sharing session variables across multiple servers in a server farm requires additional considerations, and (3) a professionally-designed app must guard against session expiration (don't just cast a session variable and use it - if the session has expired the cast will throw an error). However, for the vast majority of applications, session variables are unquestionably the way to go.
The alternative is to pass each form's information along in the URL. The primary problem with this approach is that you'll have to be extremely careful about "passing along" information. For example, if you are collecting information in four pages, you would need to collect information in the first, pass it in the URL to the second page where you must store it in that page's viewstate. Then, when calling the third page, you'll collect form data from the second page plus the viewstate variables and encode both in the URL, etc. If you have five or more pages or if the visitor will be jumping around the site, you'll have a real mess on your hands. Keep in mind also that all information will need to A) be serialized to a URL-safe string and B) encoded in such a manner as to prevent simple URL-based hacks (e.g. if you put the price in clear-text and pass it along, someone could change the price). Note that you can reduce some of these problems by creating a kind of "session manager" and have it manage the URL strings for you but you would still have to be extremely sensitive to the possibility that any given link could blow away someone's entire session if it isn't managed properly.
In the end, I use URL variables only for passing along very limited data from one page to the next (e.g. an item's ID as encoded in a link to that item).
Let us assume, then, that you would indeed manage a user's data using the built-in Sessions capability. Why would someone tell you that "Session is evil"? Well, in addition to the memory load, server-farm, and expiration considerations presented above, the primary critique of Session variables that they are, effectively, untyped variables.
Fortunately, prudent use of Session variables can avoid memory problems (big items should be kept in the database anyhow) and if you are running a site large enough to need a server farm, there are plenty of mechanisms available for sharing state built in to ASP.NET (hint: you will not use inproc storage).
To avoid essentially all of the rest of Session's drawbacks, I recommend that implement an object to hold your session data as well as some simple Session object management capabilities. Then build these into a descendent of the Page class and use this descendent Page class for all of your pages. It is then a simple matter to access your Session data via the page class as a set of strongly-typed values. Note that your Object's fields will give you a way to access each of your "session variables" in a strongly typed manner (e.g. one field per variable).
Let me know if this is a straightforward task for you or if you'd like some sample code!
As far as I know, Session is the intended way of storing this information. Please keep in mind that session state generally is stored in the process by default. If you have multiple web servers, or if there is an IIS reboot, you lose session state. This can be fixed by using a ASP.NET State Service, or even an SQL database to store sessions. This ensures people get their session back, even if they are rerouted to a different web server, or in case of a recycle of the worker process.
One of the reasons for its sinister reputation is that hurried developers overuse it with string literals in UI code (rather than a helper class like yours) as the item keys, and end up with a big bag of untestable promiscuous state. Some sort of wrapper is an entry-level requirement for non-evil session use.
As for "Session being evil" ... if you were developing in classic ASP I would have to agree, but ASP.NET/IIS does a much better job.
The real question is what is the best way to maintain state. In our case, when it comes to the current logged in user, we store that object in Session, as we are constantly referring to it for their name, email address, authorization and so forth.
Other little tidbits of information that doesn't need any long-term persistence we use a combination of cookies and viewstate.
When you want to store information that can be accessed globally in your web application, a way of doing this is the ThreadStatic attribute. This turns a static member of a Class into a member that is shared by the current thread, but not other threads. The advantage of ThreadStatic is that you don't have to have a web context available. For instance, if you have a back end that does not reference System.Web, but want to share information there as well, you can set the user's id at the beginning of every request in the ThreadStatic property, and reference it in your dependency without the need of having access to the Session object.
Because it is static but only to a single thread, we ensure that other simultaneous visitors don't get our session. This works, as long as you ensure that the property is reset for every request. This makes it an ideal companion to cookies.
I think using Session object is OK in this case, but you should remember Session can expire if there is no browser activity for long time (HttpSessionState.Timeout property determines in how many minutes session-state provider terminates the session), so it's better to check for value existence before return:
public static Account GetCurrentAccount(HttpSessionState session)
{
if (Session[ACCOUNT]!=null)
return (Account)Session[ACCOUNT];
else
throw new Exception("Can't get current account. Session expired.");
}
http://www.tigraine.at/2008/07/17/session-handling-in-aspnet/
hope this helps.
Short term information, that only needs to live until the next request, can also be stored in the ViewState. This means that objects are serialized and stored in the page sent to the browser, which is then posted back to the server on a click event or similar. Then the ViewState is decoded and turned into objects again, ready to be retrieved.
Sessions are not evil, they serve an important function in ASP.NET application, serving data that must be shared between multiple pages during a user's "session". There are some suggestions, I would say to use SQL Session management when ever possible, and make certain that the objects you are using in your session collection are "serializable". The best practices would be to use the session object when you absolutely need to share state information across pages, and don't use it when you don't need to. The information is not going to be available client side, A session key is kept either in a cookie, or through the query string, or using other methods depending on how it is configured, and then the session objects are available in the database table (unless you use InProc, in which case your sessions will have the chance of being blown away during a reload of the site, or will be rendered almost useless in most clustered environments).
I think the "evil" comes from over-using the session. If you just stick anything and everything in it (like using global variables for everything) you will end up having poor performance and just a mess.
Anything you put in the session object stays there for the duration of the session unless it is cleaned up. Poor management of memory stored using inproc and stateserver will force you to scale out earlier than necessary. Store only an ID for the session/user in the session and load what is needed into the cache object on demand using a helper class. That way you can fine tune it's lifetime according to how often that data us used. The next version of asp.net may have a distributed cache(rumor).
Session as evil: Not in ASP.NET, properly configured. Yes, it's ideal to be as stateless as possible, but the reality is that you can't get there from here. You can, however, make Session behave in ways that lessen its impact -- Notably StateServer or database sessions.