I mean web server when recieves request from the same browser/client again and again it does not know it or handles each request as request from a new browser or new request.
Keeping the above point in mind , we can have few queries.
How are web applications able to maintain user credentials among different pages when navigated. This should not be possible when each request made to web server for different pages to navigate is a new request (state less) from web server side.
It is made possible by using these sessions, Viewstates and few others to provide persistence of data/information among requests between server and client.
1) Viewstate:-
This helps to persist/hold values in specific page and purely handled on client side.
But remember this is different to cookies.
Cookies are stored but Viewstate value is hold. The exact difference is Viewstate values are not in existence when user navigates to another page.
Where as cookies can still be accessed from another page since they are stored.
Viewstate values are saved on the page as information or html data on the browser as
“Hidden value”, so when post back happens in the page, it sends the hidden values (Viewstate values) to web server from which server can retrieve and probably do required actions.
Sine I said Viewstate values are stored on client browser when page is loaded, so it very clear that Viewstate value can hold only strings.
So I mean to say that Viewstate is valid for all kind of objects which are serializable.
Since Viewstate is meant to be loaded on client’s browser, it is suggested not to store secured data in Viewstate object.
Example:-
 |
i) I have created an aspx page in my web site.
ii) Then added a Viewstate value whose key is “Name” and value is “Srinivas” in page load event of added aspx page.
Note: - We key “Name”, is used further in this page to retrieve its value (“Srinivas”);
iii) Output
 |
iv) Right click on the page and say “View source” to look into html content.
 |
We can find the input type = hidden whose id is “_VIEWSTATE” that holds the Viewstate objects. The values of the Viewstates are encrypted and this is configurable.
2) Session:-
This helps to persist/store on server side which are specific to user as Viewstate specific to a web page.
Since these session values are stored on server side, client is not aware about this data that is been maintained in session.
So when request comes from same browser multiple times to a web server, though it is state less since a session is allotted for that user, so required information that is important can be stored in session.
So when request comes from same browser, though server cannot find it is the request from same client but can access the information stored in session variable.
Even when user navigates among different pages the session values persist, as they are stored in server memory.
Session variables are meant to be expired when user closes the browser.
Note:-
Web server has an option saying “Session timed out” which is configurable, this mean when user opens the application and is not interacting with it (not sending request to web server) for a time more than this “Session timed out” value , session of that specific user is expired. At this instant if user sends request to web server, it cannot access session data that is stored earlier as it is expired.
As Session variables are stored in server memory it can be used to store any kind of objects which are not even serializable.
I am taking the same page as example replacing “Viewstate” with “session”
Example:-
i)
 |
ii) Run the application
iii) Right click on the page and say “View source” to look into html content.
 |
Still you can see Viewstate values rendered.
This is because web server appends the Viewstate values to hold the state of controls used in this page.
But this Viewstate does not include the encrypted content for Name=Srinivas.
So session is very different to Viewstate to store values.
No comments:
Post a Comment