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.
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.
I've got, probably, a very basic question about sessions.
In the page load function i have the following code:
Session["loggedInUserId"] = userId;
Now the question is:
if this code is on a server and two users connect to this server and log in one after another, would the one that logs in second be logged in already as the first user?
Do i need multithreading?
Asp.net session is per browser session. two browsers in same machine or two users in two separate machines will be referencing different sessions so dont worry.
if your are setting userId variable as static then it will be possibe other wise there will be no problem
Not needed. Please go through ASP.NET Session State (MSDN) post.
According to this
ASP maintains session state by providing the client with a unique key assigned to the user when the session begins. This key is stored in an HTTP cookie that the client sends to the server on each request. The server can then read the key from the cookie and re-inflate the server session state.
Hope this is what you are looking for.
A session is per-browser state management. A unique session ID is stored in a cookie for that browser. Never store sensitive information in a session since the session ID is sent back and forth in plain text and thus could be used by an outside source.
Read more about Sessions here.
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 am developing a web application where UserId and RoleId plays a vital role... Is it secure to store these values in session.Someother can be hiddenfield,cookie.. Which is more secured?
Any suggestion for this...
Sessions are more secure than cookies and hidden fields because they are kept on the server. Cookies usually shouldn't contain sensitive data, even encrypted, as users have direct access to them. Hidden fields are also sent to the client, but simply not displayed. Therefore, using tools such as FireBug, you can easily display this content.
There are various places you can store the session, such as in memory (if you're not using them much) or have a SQL server maintaining them. You can get more information on sessions here. Sessions are secure because of the fact that they are stored server side.
Session variables are more secure than cookies, because they're on your server, not the user's computer. Sessions aren't perfect though -- they can be hijacked by stealing the session key. Still, this is more difficult to do than just taking a cookie that's been saved on a computer.
When I need to store "vulnerable" data in session I encrypt the data before storing. The encryption options are created dynamically and are not stored anywhere so if the session ID is compromised, the hacker has no way of decrypting the data. There is a performance overhead so I only store values that need to be secure.
Session is definitely more secure than hidden fields or cookies.
The difference is the SESSION values are stored on the SERVER, and hidden fields and cookies are stored on the client.
Session would be more secure than a cookie (session is stored in memory on the server, where the cookie goes to the client).
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.