When we add a variable to ASP.NET Session, where are those variables actually stored on the client side?
If you are using the default session in ASP.NET then it is stored in memory inside the ASP.NET worker process. It is a server side cache, nothing at all to do with the client.
There are other session store options available such as dedicated session state machine or sql server. You can also roll your own session provider.
All explained here http://msdn.microsoft.com/en-us/library/ms972429.aspx
The client is given a cookie to identify it (ASP.NET_SessionId) but all the values are stored on the server.
If you use Firebug or Fiddler you can see this being set. You can see what the value is by using Session.SessionID.ToString()
As redsquare suggests the default configuration is to store all the values in the memory of the server (one reason to limit what you store in session) but you can also store it in sql server, state server or your own provider if you wish,
If you alter the value in the identifying cooking then it will alter who the server thinks you are when it comes to returning session variables. We use this feature to help us debug what is in users sessions.
I think also the identifying session cookie has a property called something like HttpReadOnly set so it cannot be read from javascript for security reasons.
The session is stored on the web server and not the client. ASP.NET usually stores a key to the session in a cookie and uses this to identify your session next time you contact the web server.
Related
Please help me whether my understanding is right.
ASP.NET sessions are stored on the web server and no cookies whatsoever are used for this.
ASP.NET if configured to use session with webconfig->session state: then we can configure it as either stateconnection or as sqlconnection.
ASP.NET if configured to use session state (either as stateconnection or as sqlconnection) then when user uses sessions in code then the cookies on client machine are used unless you specify in webconfig that cookieless=true
If we use <sessionState cookieless="true" /> then by default the stateconnection is set to localhost
When talking about Session in many dynamic web sites you want to store user data between HTTP requests (because http is stateless and you can't otherwise associate a request to any other request), but you don't want that data to be readable / editable at client side because you don't want the client to play around with that data without passing through your (server side) code.
The solution is to store that data server side, give it an "id", and let the client only know (and pass back at every http request) that id. There you go, sessions implemented. Or you can use the client as a convenient remote storage, but you would encrypt the data and keep the secret server-side.
Of course there are other aspects to consider, like you don't want people to hijack other's sessions, you want sessions to not last forever but to expire, and so on.
Session State contains information that is pertaining to a specific session (by a particular client/browser/machine) with the server. It's a way to track what the user is doing on the site.. across multiple pages...amid the statelessness of the Web. e.g. the contents of a particular user's shopping cart is session data. Cookies can be used for session state.
Cookies are small pieces of text, stored on the client's computer to be used only by the website setting the cookies. This allows webapplications to save information for the user, and then re-use it on each page if needed.
Every session will have SessionID. And Session ID is a unique number, server assigns to a specific user, during his visit(session). And defaultely, session ID is attached to a cookie and this cookie will be shared from client to server (and server to client) during its requests/responses. And server will identify session based on session id which is retrieved from cookie.
And regarding cookieless, if your browser doesnt support cookie or disabled, then cookieless will be used. Since it is Cookieless, asp.net can not create a cookie to save session id. Instead, the session id will be passed in query string.
Session : stored on server (memory or DB) and all pages in web application can use data in it.
Session State : store and retrieve values for a user as the user navigates pages in a web application.
Cookies : stored on client side as a file containing non sensitive data, but data like user favorites and preferences.
Cookieless : pass session id in URL query string and not storing it in cookies, in case you expect user to prevent or delete cookies.
Here I want to know different types of Session in ASP.NET and not Session States. That was the question asked in an interview.
Session-State modes are 5 type:
InProc mode: which stores session state in memory on the Web server. This is the default.
StateServer mode: which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
Custom mode: which enables you to specify a custom storage provider.
Off mode: which disables session state.
Check the detail. https://msdn.microsoft.com/en-us/library/ms178586.aspx
Typical sessions are based on a cookie. The server gives you one, you send it to the server upon every request. However, Asp.net allows you a different type of sessions as well - cookieless sessions. The session id is then "stored" in the URL address. This technique is very dangerous if used improperly.
Would definitely need more clarification from the OP. I feel the terms are being used inter-changeably.
By nature web is state-less. To overcome this ASP.Net provides several state management options like viewstate, controlstate etc. Session State is one of these options.
ASP.NET session state supports several storage options for session variables. Each option is identified as a session-state mode type. There are four mode types or just modes. In-Process mode, State Server mode, SQL Server mode, Custom mode and Off mode. These are modes. In-Process mode uses memory as session storage. State Server mode uses state-server as session storage. And so on. Besides, when a mode is specified by way of web.config, some additional parameters are also required like connectionstring, timeout etc. One of these parameters is "cookieless" for which the default value is "AutoDetect". If specified as "true", it will embed the ID in url. (As explained by #naivists). Cookieless option can be used with any mode.
This is all what there is to ASP.Net Session. I feel there is just some confusion on terms state, mode, mode type, storage etc. being used interchangeably. Apart from that there should be no other separate thing as "session type".
There are three kinds of session, and they are listed as follows
Inprocess.
Outprocess.
Sql server session.
where they are stored.
inproc - default stored in web.config.
outproc - stored in server side.
Sql server - stored in database.
You have following types of session management in asp.net which you can define in your web.config file
Session mode="inproc"...means the session will be stored on the webserver within your application
session mode="outproc"....means session will be stored on the server outside your application
session mode="stateserver"...means session will be stored in a temporary memory in the database
session mode="sqlserver"...means session will be stored in the database permanently.
three types of session in asp.net.
inprocess session
out Process session
SQl-server session
i was recently digging about cookieless sessions, i came accross an article which says that whenever the session is created on the server, its ID is stored in the cookies, on the client machine, i was being thought in my college that sessions are stored on the server, and if the sessionID is in cookies and cookies are stored in clients machine locally, how one can say that session are stored on server, is that right, that sessions are stored on server? if yes then what is the concept of cookieless session, can anyone explain me
Session state is (almost always) stored on the server, and it is identified by a random number, the session token.
That token needs to be stored by the client, and sent to the server along with his HTTP requests (so that the server can remember that he has seen him before and associate the session to the request).
how one can say that session are stored on server, is that right, that sessions are stored on server?
Only the session token is stored on the client, and since it is a random number, it does not contain any useful information in itself. It only becomes valuable together with the data stored on the server.
if yes then what is the concept of cookieless session
The easiest way to store the token is using cookies. That is what cookies were invented for. Alternatives are handing the cookie back and forth using hidden form variables or as part of the URL.
Session is stored on the server. Each session associated with ID (the simplest session state provider in ASP.NET is just a dictionary in memory with IDs as a keys). This ID is stored in client's cookie as well, but in case of cookieless sessions, ID is stored in the URL (example).
Think of the Session ID as a key in a table, and Session state as the value. Only the key gets sent to clients, not the value.
In the case of ASP.NET, Session state itself is a Dictionary that contains key / value pairs.
If you're using the standard SQL Server session provider, the table I mentioned above is called ASPStateTempSessions. SessionId is the PK, and the serialized Dictionary is stored in either the SessionItemShort or SessionItemLong column.
I was wondering if HttpContext.Session uses cookies to store data. A work colleague told me that in a mobi site, phones generally do not have cookies and therefore you don't have session. I always thought session is data that is stored on the server side and is not dependant on client side objects please explain if I am wrong.
I read this.
In ASP.NET; you have a Session cookie. This cookie is used to identify which session is yours; but doesn't actually contain the session information.
By default, ASP.NET will store session information in memory inside of the worker process (InProc), typically w3wp.exe. There are other modes for storing session, such as Out of Proc and a SQL Server.
ASP.NET by default uses a cookie; but can be configured to be "cookieless" if you really need it; which instead stores your Session ID in the URL itself. This typically has several disadvantages; such as maintence of links become difficult, people bookmarking URLs with expired session IDs (so you need to handle expired session IDs, etc). Most modern phones, even non-smart phones, support cookies. Older phones may not. Whether you need to support cookieless sessions is up to you.
If your URL looked like this:
http://www.example.com/page.aspx
A cookieless URL would look like this:
http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/page.aspx
Where lit3py55t21z5v55vlm25s55 is a session ID.
You can learn more about ASP.NET's session state here
The session data is stored on the server, but it also stores an id string in a cookie to identify the user.
If cookies are not supported, the id string can't be stored, and the server can't pair the session when the user makes another request.
The session id is just a number generated by the server (either from a counter or randomly), so it doesn't contain any information from the data that you store in the session object.
(The application can also be configured to put the session in the URL instead of in a cookie. This enables you to use sessions without cookies, but it ruins your nice URLs.)
Nowadays it can be both.
Server Session
Server Side session already explained in the others posts. The session is stored on the server but it need a cookie to store an indicator of who is requesting the session value.
Client Session
The new concept of WebStorage defined by W3C shows how a client side session is nowasays needed.
Here is the HTML5 implementation of a WebStorage:
https://code.google.com/p/sessionstorage/
This is a tricky question in some ways, as it is a bit of both.
The session state, itself, is stored on the server. But, you need some type of indicator on the client to use it. Normally, this is a server cookie, which is very thin and is basically a GUID for the session and nothing more. But, you can set up sites to pass the session ID in the URI, so it need not be a cookie.
Not sure how phones deal with the session cookie concept, but since I can log in, and do not see IDs in URIs, I assume there is a mechanism, even if it does not handle user cookies.
Session id is by defauld stored as cookie. You can also configure your session to pass its id as a query parameter ("cookieless").
I have a need to maintain the session state in the database. However I cannot access the database directly from the web server. The web server communicates with an app server which in turn has access to the database.
Is there a way to configure this? Or does a custom component have to be written.
The reason for this setup is to allow for load balancing and to allow the session of a user to be redirected from one server to another.
Use the ASP.NET Session State service, You can run this service directly on your app server - see notes on MSDN here - and configure all your web hosts to store their user session state on that central state server. The ASP.NET Session State service stores sessions in memory on the app server, and doesn't require a SQL Server database.
Note that if you think you need to store sessions in the database because you are using more than one web server, that is not the case: you can use StateServer. That means you enable the session state service on one machine and set up that machine in the web.config of all your web servers so that they all use the same machine for state.
Your only option is to build a custom component.
They really aren't that difficult to do as the only thing you need is for the browser to send you a value from either a cookie or the query string. What's stored is simply name value pairs.
see http://msdn.microsoft.com/en-us/library/aa479034.aspx
You can write a custom SessionState provider.. I think it's the only way.. Have a look on MSDN here.