every one know session value are stored in server and asp.net generate key for every session variable that is stored in cookies.This raised two questions in my mind
1. where exactly session variable stored in server.I mean in which file and where is it located in server ?
2. is there any way to get session value from cookies ?
1) where exactly session variable stored in server.
That depends on where you told it to. By default it goes in the memory of your webserver. But you could configure it also to be stored out-of-process or even in SQL server. Take a look at the session state modes. For example if you are running in a webfarm, you definitely don't want your session to be stored in-memory because the nodes of your webfarm won't be able to share this information between them.
2) is there any way to get session value from cookies ?
No, absolutely no. That would completely defeat the whole security of the session (which as you correctly stated is only stored on the server). The cookie value is just a pointer to this information. If you wanted to retrieve some session value from the client side you will have to write an endpoint and explicitly expose it.
Related
I was reading an article on asp.net session vs viewstate and after reading the article I got a doubt i.e. the article says if I create a session variable i.e.
Session("username")="username" this value is saved on webserver and webserver on start of first request creates a cookie and store it on a client machine and then retrieve the session variables for specific user based on the cookie value stored on client machine.
My doubts are - How and where does the session variables are stored on the server.
My understanding is based on the sessionID i.e. cookie value stored on client machine the webserver created a folder and for all the session variables created it create file and store the data i.e. For all the session variables stored on webserver there will be only one cookie stored on client machine- Please correct me if I am wrong in understanding to what I mentioned above.
ASP.Net allows you to configure where you want your sessions variables stored. The documentation on the different options you can use is available here:
https://msdn.microsoft.com/en-us/library/ms178586%28v=vs.140%29.aspx
The short version is that session variables are stored in memory with your application by default, but you can also use a separate process or even Sql Server. None of the options uses a folder on your disk, though. That would be slow. If you really want to use a folder on the server, you have to write your own custom provider.
In my project I use session to store user information ( username, password, personal image, and gender ) to be used in all pages of my project. I also use two other session to store small strings. Is there any disadvantage of using session ? also is there any risk of using session to store user password ?
Some things to take into account:
Don't store passwords. You should hash the incoming password, validate against the hash in your DB, and not hold on to it afterwards.
You should try to avoid using a write-access Session throughout the application, since you'll end up forcing asp.net to serialize incoming requests from the same session. Use read-only Session to avoid that. This could become apparent if you initiate multiple ajax calls simultaneously. More info here: https://connect.microsoft.com/VisualStudio/feedback/details/610820/session-based-asp-net-requests-are-serialized-and-processed-in-a-seemingly-inverse-order
Storing too much data in the Session could cause scalability issues, since all that information is held in memory on the server. If you switch over to SQL storage for sessions (common in webfarm/cloud deployments), then if the session is large every request on the server will have that Session data going back and forth between the server and the DB.
Content that goes into the session should be Serializable, just in case you decide to move over to a different persistent storage (such as sql server)
Using Sessions to retain information may not go well with stateless REST/WebApi endpoints (if you need to create any in the future)
Excessive use of Session for storage could make unit testing slightly more difficult (you will have to mock the Session)
By "personal image" I assume you are storing a url or such, and not an actual binary image. Avoid storing binary content. Only return the binary image file when the browser requests it, and don't store it in memory, the browser can cache that content easily.
You might also find the references linked in this answer to be useful in providing additional information: https://stackoverflow.com/a/15878291/1373170
The main problem with using Session and any machine depending properties is the scalability of the web site, so if you wanted to deploy your web site to a farm of servers then you can see the problem with depending on a machine state property since the request may be processed on different machines.
Hope that helps.
In our application, we have a "BasePage" that declares a number of properties to be used by more or less every page in the app.
Inside these properties, they write to ViewState. These are all typically an int or small string value, nothing huge. Typical use is call a web service and hold an id for use within the page, for example.
I've used viewstate since I'm wary of the loss of session variables should IIS recycle for example. Also, I figured, very small values would not add hugely to the page size.
Am I being overly paranoid about session though and would it have been a better option.
Our environment is a 2 server cluster with SSL termination on each server, sticky sessions maintained by the load balancer - so using In Proc is not a problem per say, I'm just very wary of it.
Never trust your user sent data.
Even all data you receive is not sensitive, if you send it to your user browser, you should to check it again before use it. Maybe most users are legitimate, but just one can break your application.
What are your options to store data?
Hidden field; can ve easily tampered at client side
Cookie; ancient method to keep user specific data, but very size limited.
ViewState; your data go to client and come back, using bandwidth and could be tampered.
Session, InProc; your never have problems, until a application pool get recycled
Session, State server; you keep your session data in another server process.
Session, database; can work with almost (if not all) load balance scenarios, as you dont need stick sessions, nor to worry with app pools recycling. All your data are belong to us your SQL Server.
Reading your scenario, you probably need to deal with out-of-process session storage.
I think it's best to avoid using Session state where possible, especially on a server cluster even if you are using sticky sessions. Sessions can expire, or disappear when IIS recycles (like you said).
I'd go with keeping the values in ViewState or a cookie.
If it is not sensitive data, I would also prefer to store it in the HTML rather than the session.
I'm trying to understand when I can put certain objects into a users session and am wondering how the session is stored and values retrieved from it. If I make a request to pull Key A from the session state will it also read Key B?
I know that viewstate is stored as one big object andn I am going ot assume that it is then accessed from my code once it's been entireely loaded. Is this similar for session state data or does it only load the keys that are requested form the server.
So if my state is 20KB and I want to get a value that's 5KB from it will it read all 20KB or just the 5KB that I need?
By default, session state is stored in memory until the session expires (a period of inactivity from a given user). The view state is not stored at all between requests, but is actually sent to the page as a hidden form field. This data is sent back to the server on subsequent requests.
To answer your question, the default behavior is that the entire session is ALREADY loaded so whether or not you actually access it, it is there and in memory.
There are several options for managing this however, and you can find an excellent reference here:
http://msdn.microsoft.com/en-us/library/z1hkazw7.aspx
By default, a users session is stored in memory. You could configure it to be stored in the database, but it is serialized, and read out completely when re-instantiated.
So yes, if you have 20KB worth of data in your users session, it will always use 20KB of memory.
Does IIS create the session id when a request is received and where is that saved (client or server)?
How does server recognize that the request is coming from the same user/session?
The answer to your first question is Yes -- if sessions are used, and Both.
A cookie is a short bit of text passed back and forth between client and server with every request/response.
IIS generates a session id, saves it, and any associated data, and passes the in a cookie to the client (browser).
When the client makes another request, it sends the cookie, containing the sessionID back to the server. The server can then look at the cookie and find the session (and the associated data) which is saved on the server.
In ASP.net, there are multiple places for the session to be saved, but it's always within the server infrastructure.
The default is the memory of the IIS Process. This means: if you reset IIS (or the whole PC) or even just the application pool within IIS, all sessions are deleted, and the session data is lost forever. Also, if you have a LOT of sessions and store a lot of data in each session, the process will require a lot of memory, which can be a problem. This is called "In-Proc" Sessions.
The main alternative is a SQL Server Database. That way, sessions are kept even after a restart and it does not really matter how large each session is. The main downside is the added latency: Fetching data from a database is slower that the In-Proc solution of course.
There are also some other methods how to store sessions (including the option to write a completely new session provider), but the two common ones are "The Memory of the Server" and "A MS SQL Database".