Once again the confusion related to MSDN documentation with respect to Session Management.
I went thru the Session Management Article in MSDN, and found that it is stated in the article that - "we can Store session-specific data on the server for use across multiple browser or client-device requests within the same session."
Can anybody tell me how is it possible. for e.g. if you have two browsers i.e. i)Firefox and ii) Internet Explorer (IE).
Now, If I am running asp.net application (which uses stateserver to manage sessions) in Firefox. And again the same application I ran through IE (without closing firefox session). Is that means that both the browser will share the same session? I guess "NO". Both the browsers will run with their own sessions, which is different from each other.
Secondly, I found that the two statements in the article are contradictory with each other. It says that - "Session state is similar to application state, except that it is scoped to the current browser session" and on other hand it says that - "It Store session-specific data on the server for use across multiple browser or client-device requests within the same session"
So, if its scope is limited to the current browser session, then how it can be use across multiple browsers?
It is a little confusing, but I think you're misinterpreting the statement. They are referring to multiple requests, not browsers or client-devices.
Session is indeed scoped to the current browser session, persisted with cookies or query strings.
In general, sessions are handled through cookies. Each browser implementation (IE, Chrome) has its own cookie store. Therefore, different browser implementations aren't going to be able to share sessions without some significant workarounds.
Multiple instances of the same browser can reference the same session because they all have access to the same cookies. This can be described as "multiple browsers".
Related
Maybe I'm missing some fundamentals about this, I just don't get why Form Authentication is not build in top of Session.
I've had some issues with Form Authentication timeout and Session timeout, I understand how to get arround those issues thanks to blog posts like this one.
But why are they separated?
I just don't get why Form Authentication is not build in top of Session.
Forms Authentication uses cookies which are common in all applications. Only the currently authenticated username is stored into the cookie. The session on the other hand could store arbitrarily large values as it is stored on the server. You cannot persist arbitrary large data into cookies. The session state has lots of problems. For example if you are running in a web farm you need to ensure that you are using an out-of-process session persistence instead of the default InProc so that all nodes of your web farm could share the same session data. Personally I never use sessions in my applications. The very first thing I do is to ensure that I disable all session state in my web.config:
<sessionState mode="Off" />
This way I am sure that no developer working on my projects would ever do the mistake of using ASP.NET sessions. They turn web applications which are intended to be stateless into stateful.
With cookies you do not have such problems. You could throw as many nodes you want to your web farm to face increasing user load without ever worrying about any state on the server.
Basic because some may chose to use only one of them, and because they are two different modules - and both gives the interface to make a custom one.
Also one user can have session with out have never been authenticated.
Also some other (like me) can made totally custom session module, but keep the Authentication module.
So this is two different modules and they can not be connected.
What I am looking for is way / design to track a user / site visitor without the need for cookies or JavaScript as about 5% of users have one or both of these turned off.
What I would like to achieve is a unique reference for the user which can be captured server side in code.
I was thinking machine CPU / Motherboard ID but this information is hidden.
What information could you use / combine to create a unique hash.
I also need that ID to work across different sessions. Or maybe if the information is unique enough a way to do cookies/cookie type things across different browsers.
You could put a code in the url, this is how cookieless sessions used to work (maybe still do).
UPDATE: taking comment on, depending on your application and number of users you could consider giving each user a dedicated sub domain, or if subdomains are too tricky build it as part of their url. This depends on whether they need to login into the site.
You could look at doing something with client ip addresses but this would not work for everyone.
Are you sure the users really have Cookies switched off? It could be that users have persistent cookies switched off (the ones that write a file to the user's hard drive) and still have browser session cookies switched on. Browser Session cookies live in memory and disappear when the user closes their web browser, but normally this is enough for server-side Session State to work properly.
In nearly all cases where clients have cookies disabled, it's always persistent cookies only. The in-memory ones are still enabled and work fine, you can still track users, but only for as long as the browser remains open, this might be enough for you I don't know.
Update: I just noticed you said this needs to persist across sessions (as in user closing browser down and going back to site later). Have you looked at HTML5 storage options (LocalStorage in particular), it's a simple Key/Value store, and it's reasonably supported across browsers even versions of Internet Explorer.
After some more research aided by Rup and the ret of the comments on here, it has become apparent that there isn't a simple way to track a user across your site without cookies, But its not impossible.
Looks like the only way to truly achieve this is via browser finger printing, using all the information supplied back to the server to make a unique finger print of the users browser, this seams to work for about 95% about the same as cookies.
Browser finger printing at the moment seams like a workable approach but I feel there might be quite a large backlash from the general public / privacy groups if you where to go down this route.
For the moment it seems we are stuck with cookies.
I was wondering if there is a straightforward way of getting a user's session cookie and posting it to a page on a different site to be processed there?
If a diffrent site means a diffrent domain or even subdomain, the answer is no. For security reasons a cookie should not be read by other pages. And as a session cookie only contains a session ID but the actual session data is stored on the server, posting a users cookie to another site would not give you access to the users data on this page.
If example.com sets a cookie, then a page from example.com can have some script that reads the cookie and posts that information to whatever site it wants. So if the cookie is 'under your control', you can send it where ever. Generally, however, a session ID isn't useful except on the site where it came from (and it's probably a security hole that should be fixed if the cookie can leak information about the session). Actually, it's probably a security hole if your pages are giving out your session cookies to other sites.
However, browser security rules will (or at least should) prevent your page from trying to read cookies set by other sites.
Straight answer, if they are different domains, then no. If they are on the same domain, then set the cookie path to "\" and you should be set. In any case, I think it's still worthwhile to check out a technique called web beaconing and see if you can adapt any part of that method to suit your needs, should you be dealing with different domains (hope not).
http://en.wikipedia.org/wiki/Web_bug
http://www.webmaster-talk.com/javascript-forum/183163-redirect-different-page-if-no-cookie.html
This will help u..
Like Kau-Boy said:
If a diffrent site means a diffrent domain or even subdomain, the answer is no.
This is due to the SSH Secure Shell. To do it, you would be going against everything (almost) that the SSH Secure Shell does for the internet. You would have to play with some low level protocols to get all the private keys and such. If these were your servers, this might be possible; but very bug prone because these handshakes (like most) are designed to not happen the same way twice.
In a nut shell: very hard, chances of actually pulling it off: low ... what are you waiting for?
So i have a custom CMS running under .Net 3.5 written entirely in c#. The engine is optimized to render for mobile devices, but also server to normal web browsers. It also supports cookieless sessions. Great...
I've chosen not to cache anything (including browser data) in order to control the rendering completely from data. This has been all good until lately.
The engine implements a basic login function that simply logs the user state within a session object.
The behavior is rather strange. User will click through the site no problem. Then login. The login will either go through successfully or just redisplay the login screen, suggesting a cached page being returned or redisplayed... If the login is successful the concurrent page hits will switch arbitrarily between logged in and logged out state... Also suggesting either the session state is not accessible or a cached page being returned.
I have debugged the hell out of the thing.... including using fiddler and the like. When debugging the behavior disappears.
Huh?
One of the sites running on the engine is http://www.wiseguy.mobi (sorry customized for South Africa, so you'll probably not be able to get the password Text Message)!
Ok, so i've been a dumbass...
The issue was related to the fact that my IIS application was running 2 WorkerProcesses. Thus InProc Session state would return different session object states when the user hits either of the worker processes.
This is why the SQL SessionState persistance has resolved it. Either was its set up rather nicely now, and the issues have been resolved...
I have a web application that once signed in, personalizes almost all pages.
I want to be able to have some very specific pages locked down with SSL that may have sensitive information. From what I have been able to find, once you sign in via an SSL sign in page (area of the web site), the session information which I use to store a lot of personalization and user credentials is not available to the non SSL portion of the web site since they are considered 2 seperate applications.
This MSDN document pretty much says what I am talking about: MSDN Doc
Note: If you use this type of site structure, your application must not rely on the user's identity on the non-SSL pages. In the preceding configuration, no forms authentication ticket is sent for requests for non-SSL pages. As a result, the user is considered anonymous. This has implications for related features, such as personalization, that require the user name.
I am also not using forms authentication. When a user signs in a session object is made storing their credentials including their IP. If this session object exists for a particular user with the same IP then they are considered 'signed in' and the personalization features are enabled.
So my question is, are there any work arounds to this so that say my sign in page and some other page are using SSL, the reset of the site is not, and all pages have access to the same session variables?
If not can anyone suggest any other methods of accomplishing the same type of personalization features?
Since there are no comments, I thought I'd offer an inelegent but practical solution.
Leave the RequireHTTPS off in your forms authentication configuration block.
Next, you create a custom class that implements IHttpModule. This interface has an Init method that takes a HTTPApplication instance as an argument. You can then attach to the "AuthenticateRequest" event on this instance.
From here, you can 302-redirect any requests that come in without SSL when they should do. You'd probably want to drive which pages require SSL from a custom configuration section in your web.config.
To use this class for your requests, you have to add a line to the HttpModules section of the web.config.
For a start, have a look at this code project article: http://www.codeproject.com/KB/web-security/WebPageSecurity_v2.aspx - this will enable you to "step on" and "step off" of https for certain pages.
With regard to your session issues, I think you're a bit stuck. The standard forms authentication mechanism stores a cookie to identify the authenticated session which is available over http or https. My advice would be to switch to using forms authentication, and use the ProviderUserKey guid as the key for accessing your per-session data.
Hope this helps.
We have decided to not go with SSL in those few pages that required them. We looked at other web applications that did similar things and they do not use SSL. We are not really protecting anything that would be all that useful for a malicious user to go through the trouble of stealing anyways.
One option I did consider before the decision was made to remove the SSL was to store a user's session on the application's web service interface. Every page call would access the web service to access the session information. This would be enforced on every page call to ensure the session stayed active. I didn't do too much investigation into using this solution before the SSL decision was made so there could be many draw backs to this solution, especially having to make extra calls to the web service with every server hit.