I'd like to ask about strange behavior of Cache object. I use Cache to store data specific for user (more accurately for session) with SessionID as a key.
For some reason the data in Cache appears not to be the same for different subdomains. I managed to keep SessionID equal across all subdomains:
- I set domain attribute in httpCookies element in web config like ".domain.com".
- I used this trick to ensure that SessionID cookie is stored across all subdomains.
- I set sessionState mode to SQLServer.
I ensured that SessionID is really the same for all subdomains. What's more, it is interesting that when I use session state in place of cache, everything works just fine. Session returns expected data for all subdomains. But when I use cache with SessionID as a key, cache returns different data for different subdomain.
Of course, I could keep it in session state but I'm not really fan of it and try to avoid it whenever I can.
Any ideas would be appreciated.
What's more, it is interesting that when I use session state in place
of cache, everything works just fine.
It works because you store SessionState in centralized location which is SQLServer.
The Cache for the current application domain..
If you want to have same cache for all app domains, you need distributed caching such as Windows Server AppFabric
Related
I have two ASP.NET applications using Forms Authentication and Single Sign On and I would like to persist Session variables between them.
Upon testing, I cant seem to get the Session variables to be read from the other application. Both apps are on the same domain (app1.domain.com & app2.domain.com) and I have set up my config (a.f.a.i.k.) correctly to reflect this.
I have noticed that when testing on the release server the session id is different even when using tab pages on the same browser (I thought they would be the same!), yet debugging on my local IIS the session id is the same (and I still cant read session variables across sub-domains).
Anyone got any pointers to what I may have missed?
Best Regards
By default, SessionState mode is InProc which means Session State data is stored in each AppDomain's memory. AppDomains are isolated, and they do not share SessionState.
You need SQLServer or StateServer as SessionState mode.
We just upgraded to IIS7 and have had intermittent issues with SESSION variables. In a nutshell a very low percentage of users are getting new SESSION IDs with each page request. Clearing cookies has solved this problem for just about every use I've come across.
My question is... Is there a way to programmatically do this? It's been a lower percentage of calls of people unable to login/can't get a certain application to work, so it's not a HUGE deal, but we are having to walk people through the process of clearing cookies all day. I haven't read of, nor seen a way to force users to clear cookies.
Most other questions on here are uses having this issue everywhere, as if there is a programmatic error. Our applications work fine, it's just a small percentage of users who used our applications on our old server can't get new session cookies from the new server.
We were running IIS6/CF9 and we upgraded to IIS7/CF10. This problem is cross browser. We have seen it turn up in IE, FF, and Chrome.
--EDIT--
If a user clears cookies and goes to domian.com and then to sub.domain.com, the domain.com cookie takes precedent and the browser I guess never returns the sub.domain.com cookie it gets from the sub.domain.com server. Turning on J2EE cookies on sub.domain.com fixes the issue, I guess, but the clients still run around with a cookie from domain.com. domain cookies is whatever is set by default... i.e. we don't set it to anything in app.cfc. I have no idea how it is set on domain.com.
In Application.cfc do you have domain cookies set to true?
Sounds like it could be related to the session fixation Hotfix Adobe introduced in February last year. Was your CF9 server fully patched?
In short, CF now issues new CFID/TOKEN values on every session and won't use existing cookie values (to prevent session hijacking). Make sure your app is writing these new values to cookies and not allowing existing cookie values to be used.
Here's a detailed explanation As pointed out in the comments on that post, using J2EE sessions is indeed one way of solving the problem.
It seems like there are a lot of ways but no default. For State management, does ASP.NET use cookies by default?
If so, what are the alternatives to using cookies?
If not, what does ASP.NET use by default to manage state?
Yes - by default, ASP.NET uses cookies to maintain session.
That is, a unique "Session Identifier" cookie is stored on the client to keep track of sessions on the server (state service, sql db, etc).
But in the web.config, you can set cookieless to true:
<sessionState mode="InProc" cookieless="true" timeout="20" />
This will cause that very same "Session Identifier" to be stuck in the URL, and no cookies will be used.
Don't get confused though - the cookies dont store the actual "session". It sounds like you think cookies can be used as an alternative to something like the ASP.NET state service.
When in fact, the cookie just stores an identifer in order to "track" the session, in other words - this "identifier" is passed between the client-server on every HTTP request, this way the server can synchronize a particular session item with the client it belongs to.
Cookie-based/Cookieless session is irrespectible of what actual state storage mechanism you have in place - whether it be In Process session, ASP.NET State Service or SQL Server. It simply dictates the way in which the server is allowed to keep track of sessions.
Of course, cookieless sessions will suit clients that are likely to turn cookies off, but the disadvantage of this is you have ugly URL's, but this can be negated quite easily with the use of URL rewriting, although i would recommend against this - many have reported problems in attempting to do so.
HTH
I have two identical applications setup on IIS on different virtual directories (I have done some workaround to ensure that they both have the same application name). Is there a way to share session id across two asp.net web applications?
Since I'm storing the session in StateServer, they should both be getting the same session data, however, a different session id is created everytime I go from application a to applicatino b. Wouldn't this happen in a load balancing scenario as well? Where when I go to www.test.com, it would redirect that request to server a, and then if I hit it again, it would go to server b, but since it's a different web application, it would create a new session id?
First, configure the sessionState element in your web.config to use cookieName="SOME_COOKIE_NAME_HERE" in both apps.
Then, just make sure the urls have the same TLD (top-level domain), i.e. app1.mydomain.com and app2.mydomain.com and you should be able to handle the Session_Start event in Global.asax and put this code:
HttpCookie cookie = new HttpCookie("SOME_COOKIE_NAME_HERE", Session.SessionID.ToString());
cookie.Expires = DateTime.Now.AddMinutes(20);
cookie.Domain = "*.mydomain.com";
cookie.HttpOnly = true;
Response.SetCookie(cookie);
Also, I would recommend that you go with the SqlServer SessionState Mode.
Initially i faced the same issue. What I did is, I overide the jsession id from each domain. I mean, If the user lands on domain1.com, set the same session id for domain2.com from iframe. and vice versa. With this, you can maintain same session across multiple domains.
You need to test the impact over multiple server over network with load balancer.
Is your goal to share the session state between 2 applications, not just the session ID? I believe the StateServer also uses the application path as well as the SessionID to store the data so even if the SessionID's were the same you still wouldn't be able to share the data. You might have to write your own session module.
Load balancing web apps don't have this problem because the application path is the same across cluster members.
My forms are losing session variables on shared hosting very quickly (webhost4life), and I think I want to replace them with cookies. Does the following look reasonable for tracking an ID from form to form:
if(Request.Cookies["currentForm"] == null)
return;
projectID = new Guid(Request.Cookies["currentForm"]["selectedProjectID"]);
Response.Cookies["currentForm"]["selectedProjectID"] = Request.Cookies["currentForm"]["selectedProjectID"];
Note that I am setting the Response cookie in all the forms after I read the Request cookie. Is this necessary? Do the Request cookies copy to the Response automatically?
I'm setting no properties on the cookies and create them this way:
Response.Cookies["currentForm"]["selectedProjectID"] = someGuid.ToString();
The intention is that these are temporary header cookies, not persisted on the client any longer than the browser session. I ask this since I don't often write websites.
Before changing any code, I would investigate why session variables are disappearing.
Perhaps it is as simple as changing the timeout setting in the web.config?
Here's a list of the session state settings in the config file: Session Element on MSDN
====================================================
Oh yeah, one other thing to try in relation to your comment:
If my memory serves me, we had some issues in the past when deploying to a web garden/farm where multiple web sites on the same server would "clash". To get round this we explicitly names the cookie as so:
<authentication mode="Forms" >
<forms loginUrl="your-login-page.aspx"
cookieless="AutoDetect"
name=".A-NAME-WHICH-IS-UNIQUE" />
</authentication>
Name: Optional attribute.
Specifies the HTTP cookie to use for authentication. If multiple applications are running on a single server and each application requires a unique cookie, you must configure the cookie name in each Web.config file for each application.
The default is ".ASPXAUTH".
From here link text
No you do not have to keep resetting the cookie in the response.
Once set that cookie will continue to be sent with each subsquent request.
However I agree with Dominic you should first determine the reason you are unable to maintain the session in the first place.
Some reasons are:-
The host is using a web garden or a load balancer that does not support session affiliation
There is an aggressive setting for session timeout on the host
The host has a problem and is recycling the application pool frequently
Your client has overly tight cookie settings and is rejecting all cookies (however that would mean your alternative solution wouldn't work either)
Application logic may be faulty causing Session.Abandon or Session.Clear when it ought not.
In answer to your question about copying the cookie from the request to the response, no this is not necessary.
When the cookie is created it can persist for as long as you require.
If it is just needed for the duration of the session then do not set anything against the Expires property. In this case the cookie will be held in the browser memory and served up with each request to you website until the browser is closed.
If it is to persist between sessions the set the appropriate DateTime value against the Expires property. In this case the cookie is written as a file on the client machine and continue to be served up with each request to your website until it's exiry date is reached or it is deleted.
Of course, be aware clients can disble cookies in their browser.
I do agree with previous answer, that you should investigate the sessions timing out first!
But regarding cookies:
Request cookies are the cookies sent from the client to the server and Response cookies are the ones sent from server, telling the client to save them locally and attach them to the next, and all upcoming until the cookie is outdated, requests to the server.
Cookies have a limit on size and because of their behavior will create an overhead on data sent between server and client on requests, and can of course also be disabled on client side as well.
I would suspect that the reason you might be loosing session variables is that your application is running in a web garden. This means two or more processes are running your application.
In your web.config there should be sessionState tag. If mode="InProc" then try setting mode="StateServer". This will cause all the processeses hosting your application to use the session state server to store the session state elements. Also check the timeout as was mentioned previously.
The research I've done into cookies suggests they would not be a desirable alternative to session variables. Browsers enforce arbitrary limits on the number of cookies that can exist at any one time as well as the number per site. They are also prone to being dropped randomly.
You can enable cookieless sessions. There are some potential issues but it might work for your site.
I was a webhost4life customer up until two months ago, the issue I was experiencing was the application pool being recycled frequently - probably because the host had some kind of problem. In the end I moved to a VPS and never looked back (not a webhost4life VPS either).
For Sharing hosting the best approach is to use SQL Session State.
It's a little bit slower but much more reliable.
I had the same problems back in the days and my Memory Sessions were always getting erased, this happends because someone on the same hosting environment didn't know how to accomplish stings and IIS just reset the Application Pool, or it could even do by Auto Refresh the AppPool from the Hosting point of View (so no website will hang).
Since I started to use SQL State ... I just must say WOW!
you have total control in everything, even set the timeout (Memory Sessions are set by the machine config and no matter what you set in code or web config you will never override that setting)
and you gain something new, if you change the code, you users will not need to left the website to re.login again as they will continue from their existing session.
Setting it up it's fairly easy and you have a ton of examples on how to accomplish such behavior.
no matter what you do, DO NOT GO to cookies as they are not reliable!
You might consider using this little library:
http://www.codeproject.com/KB/aspnet/Univar.aspx
It can automatically switch to the session whenever the cookie is unavailable. It also has a server side implementation of the cookie whereby all cookies are stored on the server and asp.net authentification can be used to identify the user.