Curious to know the pros and cons to using Session or UrlString to carry data between pages?
Any input is appreciated!
I guess you either mean UrlData or QueryString? Or have you invented your own Web Pages version of Bradgelina?
Anyhoo, you would use Session for sensitive data that you don’t want the user to see or to be able to tamper with easily. One example might be a list of permissions that the current user has. Url based values are usually page-specific and identify the subject
matter for the current page. An example is the thread id in the url of this page.
More on transferring data in Web Pages here: http://www.mikesdotnetting.com/article/192/transferring-data-between-asp-net-web-pages
I had originally started out with Url data. It was great to see what is being passed on from one to the other page.
Just recently, I have realized that for my application it will be a recipe for disaster when users start tinkering with what is behind the link.
Converted everything to session variables.
The UrlString / QueryString Approach
I’m going to assume that the UrlString that you are referring to is the same as using QueryString parameters like those seen in the example URL below that demonstrates passing three parameters (Property, AnotherProperty and YetAnotherProperty) along
with their respective values (A,B and C) :
This is an extremely common way to pass data from one page to another as these values will be added to the Request object and will be easily available when you need to access them from the targeted page. One of the issues with using this approach is that
these values will not be persisted and will only be available when they are present in the QueryString. So if you navigated to the above URL, you would be able to access the values, but if you navigated away from that page (without re-adding the QueryString
values), they would be gone.
Another issue with the QueryString that you might hear often would be that it is susceptible to user tampering. For instance if you needed to pass across a few values, there is nothing to stop the user from changing one of your properties to whatever they
would like and resending the page. You can use various approaches to encrypt the QueryString to help prevent this issue if you elect to use it (and are concerned with issues like that).
The Session Approach
The Session differs quite a bit from the QueryString in that it is stored on the server (e.g. memory is allocated on a per user basis and stored for that user). It’s going to be more persistent than the QueryString approach in that the values will
persist across multiple pages and be accessible until they are explicitly disposed. This can be useful if you are going to have one or more values that you’ll need to "always" have access to regardless of your location in your application.
The Session doesn’t come without flaws however. It’s extremely volatile and it will be completely erased when certain events occur on the server (if the application pool is restarted, if you experience a hard-exception that forces an application pool
restart, or if you simply encounter an idle-timeout). Another extremely important consideration is system resources, the memory that is allocated for is allocated on a "by-user" basis. This can lead to some serious issues if you are storing a large amount
of information within the Session as you’ll have to consider that you are storing this same amount for every user in your system.
Pros & Cons
The QueryString / UrlString
- + Only persists for a single request. No unnecessary server-side overhead / memory usage.
- + Only passing across the data that you need, you don’t need to worry about any disposal (it’s handled for you).
- - Susceptible to "tampering" as this information is exposed to the client within the URL. You would need to encrypt to handle preventing this.
- + Persists for multiple requests and across multiple pages.
- + Not susceptible to any user tampering as it is all handled through the server-side.
- - Uses System Resources and can be very easily abused. It can lead to OutOfMemory exceptions if too much information is stored within the Session. Requires explicit disposal.
Some fantastic responses here guys! I really appreciate your help in clarifying the two and what options I have at my disposal!
Appreciate your help!