I was just curious if we can get/view Session variables values for a website using Chrome DevTools.
If anyone knows, please share.
No, you cannot view session state variables at client side. Session state is stored at server, and Client browser only knows SessionID which is stored in cookie or URL.
ASP.NET Session State Overview
Sessions are identified by a unique identifier that can be read by
using the SessionID property. When session state is enabled for an
ASP.NET application, each request for a page in the application is
examined for a SessionID value sent from the browser. If no SessionID
value is supplied, ASP.NET starts a new session and the SessionID
value for that session is sent to the browser with the response.
By default, SessionID values are stored in a cookie. However, you can
also configure the application to store SessionID values in the URL
for a "cookieless" session.
Chrome Browser has few extensions to view cookie. I use Edit This Cookie.
Session is maintained at server side. You can view cookies with session ids at client side. so chrome will help you to that only.
if you are using apache server then the file with same name as session can be found on server & all variables can be checked.
If you're on ASP.NET you could potentially use Glimpse, a client-side "inspector" that overlays your webpage and shows you what's happening on the server-side. It's great, and the plugins library makes it even nicer to see other things like DB queries the page made and so on.
http://getglimpse.com/
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'm little-bit confused about session management in MVC4.
Lets say, I entered username and password and clicked on Login button.
Then on server side, I got SessionId from HttpContext.Current.Session. And then I am validating that user credentials against database. If user is valid, then Adding SessionId, userName and uiserId in Session.
Lets say, next time request is came from same machine and same browser, I got same SessionId and then allowing that user to access other information.
Now I have following questions:
How server come to know that request is came from same browser and from same machine?
I found that, SessionId is different for different browser but it is same for same browser on different machine, so If I logged in from machine1 and with google chrome, then is it possible to use same session for different browser?(means session will be available for different machine with same browser. Is it possible?)
How server understand that request is for same user, who is logged in?
In asp.net session is maintained by viewState, but view state is not used in MVC, then what is used in MVC?
First I suggest to read this Wikipedia article about HTTP sessions. The answers on your question:
With every request the client sends its SessionId in either a cookie
or the query string.
This should not be possible by default. But it can be done by session hijacking.
The server reads the SessionId which was sent by the client in question 1. The server maintains for example a key value data object so it can load the right data for the given SessionId.
ASP MVC doesn't use a viewstate since it's a completely different approach than ASP.NET. See this question for more information.
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").
For various reasons I am fed up with ASP.NET session state and I'm trying to do it myself (separate question coming soon related to why I'm fed up and whether it's feasible to do it myself, but for now let's assume that it is).
Security concerns aside, it seems like tracking sessions involves little more than storing a cookie with a guid and associating that guid with a small "sessions" table in the database, which is keyed on the guid and contains a small number of fields to track timeout and to link to the primary key in the user's table, for those sessions that are linked to registered users.
But I'm stuck on a detail with the cookie, in the case the user's browser is not set to accept cookies. It seems to me that each time a user accesses any page that has session state enabled, ASP.NET must determine whether the browser supports cookies. If there already is a session cookie sent with the request, obviously it knows cookies are accepted.
If not, it seems like it needs to check, which as I understand it involves trying to write a cookie and redirecting to a page that tries to read the cookie. So it seems, when a user with cookies turned off visits several pages of a site, that ASP.NET
(a) has to do this round-trip test for every page the user visits, or
(b) has to assume the browser accepts cookies and create a record with a (provisional) session id for the user on each page -- and if session state is supposed to be persistent, it seems it has to write that initial session id to the database on each page.
But (a) sounds crazy and (b) sounds crazy also, since we would quickly accumulate session ids for all these single-page sessions. So I'm thinking there must be some other trick/heuristic that is used to know when to do the round-trip test and/or when to actually create a record for the session.
Am I wrong to be perplexed?
(To be clear, I'm not talking about implementing a custom storage solution within ASP.NET's pluggable session state system. I'm talking about skipping ASP.NET's session state system entirely. My question is a more detailed version of this one: Implementing own Session Management in ASP.NET.)
Session behaviour is set through the sessionState element in web.config. In the sessionState element the HttpCookieMode can be set to one of UseUri, UseCookies, AutoDetect, UseDeviceProfile.
UseUri and UseCookies tell ASP.NET explicitly how to handle storing the session identifier. If UseDeviceProfile is used then the behavior is determined by whether the user agent supports cookies (not whether they are enabled or not).
AutoDetect is the interesting case that you are interested in. How ASP.NET is handling the auto detection is explained in Understand How the ASP.NET Cookieless Feature Works. In that article you will see that they have 5 different checks they do. One of the checks is, as you mention, to set a cookie and do a redirect to see if the cookie exists. If the cookie exists, then the browser supports cookies and the sessionID cookie is set. However, this is not done on every request because another check they do before tring to redirect is is check to for the existence of any cookies. Since after the initial set-cookie and redirect the sessionID cookie will be set then the existence of the cookie lets ASP.NET know that cookies are supported and no further set-cookie and redirects are required.
Well, cookies are a standard mechanism of web authentication. Do you have any reason at all why you wouldn't want to use them? Are you sure you're not trying to invent a problem where there isn't any problem?
Most serious websites I know of require the browser to accept cookies in order for the user to be authenticated. It's safe to assume that every modern browser supports them.
There's an interesting article about cookieless ASP.NET that you should read.
EDIT:
#o.k.w: By default the session state is kept by ASP.NET in-process (read: in memory). Unless told explicitly by the configuration to store the session in the database (SQL Server is supported out-of-the-box), this won't result in a database hit. The stale session states will get purged from the in-process storage. Unfortunately, with default ASP.NET settings every cookieless request will result in a new session being created.
Here's a detailed comparison of available session storage options: http://msdn.microsoft.com/en-us/library/ms178586.aspx.
In config file I have the below settings
sessionState mode="InProc" cookieless="false"
Does this indicates that the sessionid is stroed in cookies? If yes then how is it picked and sent to the server and how is it verified across postbacks.
What will happen if cookies are disabled in my browser, will the session(sessionid and session variables) still be created?
Where(default path) are the cookies created and stored by default for sessions and can i change the path?
What format and kind of data is stored in cookies for session?
If i store a class object in session then what is actually stored in cookies?
Also if i use authentication mode as forms with cookies then what will happen if cookies are disabled in browser?
The session cookie is a special non-persistant cookie. It's only stored in memory, so in most cases even when cookies are disabled it still works fine.
It's also possible to enable something called cookieless sesssions where the sessionID is embedded in the URL, like this:
http://yourserver/folder/ (encrypted session ID here) /default.aspx
Here's a link to an MSDN article with more details: http://msdn.microsoft.com/en-us/library/aa479314.aspx
NOTE: It is possible to completely block the session cookie. For instance, in IE8, I just went into Tools > Internet Options > Privacy. When I cranked the slider up to 'High' or greater, my sites never got past the login screen because the session cookie was blocked - in fact, Josh Stodola said below that in this case the session would never even be created on the server.
However, understand that this type of behavior effectively breaks the Internet. So unless you're building a site targeted at conspiracy theorists, in my opinion (and the opinion of most of the largest sites in the world) there's no need to cater to the tiny percentage of users who don't play by the normal rules.
For them, the Internet just isn't going to work the way it's supposed to.
My guess is that each request by the client will be seen as a new session by the server.
If you happen to grab the request headers from your browser, you can see that a SessionID is part of the header. This is used by the server to determine which session belongs to which user.
Instead of session id being passed via cookie, it is typically passed as a query string in the URL, or as a custom HTTP header. With the scenario you described, however, your user will never obtain a session because you have cookieless set to false.
I have not implemented this personally. But it should be like:
As Cookiless=false in web.config file and browser has disabled cookies, when first request for the page comes, HTTP module will check for forms authentication cookie. Now it will be empty which send user to login page. Now when second request for any page on website will come it will again find forms authentication cookie empty and send user to login page. So for every request user needs to create new session.
No, If cookies are disable the session will not work.
if you want to use session when cookies disable then you can pass session thru URL.
It stores directly in the browser
There are two ways session state can store the unique ID that associates client with server session; by storing an HTTP cookie on the client or by encoding the session ID in the URL.
Session Mode="InProc" is a default mode which stores the session state information in web server. However when you say cookieless="false" you are saying to stored unique ID in cookie. This Id is created when session is created, so during postback ID is picked up from cookie. If cookie are disabled in browser,yes session still will be created and this id is passed along URL.
You can browse to cookies by going to browser settings->Privacy->Content Settings->All cookie and site data->Stored with site name
Probable you might find cookies in %userprofile%\AppData\Roaming\Microsoft\Windows\Cookies but might differ from operating system to system.
In cookies you usually store small piece of insensitive personal information. If you need to store sensitive data such as user name and password it is better to encrypt those data.
In cookie you usually store information about the users. For more details please visit URL
http://msdn.microsoft.com/en-us/library/system.web.configuration.sessionstatesection.cookieless(v=vs.110).aspx
http://msdn.microsoft.com/en-us/library/ff647070.aspx#pagexplained0002_cookielessforms