I've looked at questions such as Set Sessionstate cookieless="true" in asp .Net, is the sessions state maintained? and Which one is better, InProc or SQL Server, for Session State mode in asp.net? but wondered if there an advantage or disadvantage to cookieless in true vs. false mode assuming everything is on one server.
We're looking to have around 200 people a day register and login, mainly text with some small PDF uploads (2Mb at most and say 5 documents).
Is there any upside to show set Cookieless to True in this or any instant (again assuming one server)
No, there isn't, not for that small amount of users anyway, unless they are using clients that does not allow or support client side cookies.
If you choose cookie based sessions, the InProc is fast, StateServer slow (but works for a server farm (multiple servers)):
Have a look at these post as well, especially the first one
https://security.stackexchange.com/questions/17719/what-risks-do-cookieless-sessions-have-what-are-the-mitigations/17733
ASP.NET session vs session state and cookies vs cookie less
What are cookieless sessions?
StateServer mode is best.
It will not lost session variable values.
Also cookieless=true session is best, because coockieless=false will generate sessionstring in url path.
Any one can copy that url path to access website from other computer.
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.
Site hosted via IIS 7.0
I would like to set my session time-out to 9 hours in my ASP.NET application.
This has been set at web.config
<sessionState timeout="540"></sessionState>
But, as I understand, if the timeout is set as 20 minutes inside the IIS where the website is hosted, setting an extended session state will be of no use.
Firstly, I would like to confirm whether this assumption is right.
The problem is that I do not have access to the IIS of my shared hosted web server.
Now, after some research, I came up with another solution in code project. This sounds like a wonderful idea. The idea is to insert an iframe to master page. The iframe will contain another page with meta refresh less than 20 minutes.
Response.AddHeader("Refresh", "20");
This idea seemed good for me. But the article is 7 years old. Plus at comments section a user complaints that this won't work if the page is minimized and I am worried that the same happens when my pages tab is not active.
I would like to know these things
Whether the refresh method will work for my scenario , even if the page is minimized?
Are there any other methods that could increase session time out that overrides IIS timeout setting?
Also I read some questions in Stack Overflow where the answers state that the IIS session timeout is for clasic ASP pages. Then why is not my extended timeout not firing?
Firstly, I would like to confirm whether this assumption is right.
Yes, this assumption is absolutely right in case you are using in-memory session state mode. In this case the session is stored in memory and since IIS could tear down the AppDomain under different circumstances (period of inactivity, CPU/memory tresholds are reached, ...) the session data will be lost. You could use an out-of-process session state mode. Either StateServer or SQLServer. In the first case the session is stored in the memory of a special dedicated machine running the aspstate Windows service and in the second case it is a dedicated SQL Server. The SQL Server is the most robust but obviously the slowest.
1) Whether the refresh method will work for my scenario , even if the page is minimized?
The hidden iframe still works to maintain the session alive but as I said previously there might be some conditions when IIS unloads the application anyway (CPU/memory tresholds are reached => you could configure this in IIS as well).
2) Are there any other methods that could increase session time out that overrides IIS timeout setting?
The previous method doesn't increase the session timeout. It simply maintains the session alive by sending HTTP requests to the server at regular intervals to prevent IIS from bringing the AppDomain down.
3) Also I read some questions in Stack Overflow where the answers state
that the IIS session timeout is for clasic ASP pages. Then why is not
my extended timeout not firing?
There is no such thing as IIS session timeout. The session is an ASP.NET artifact. IIS is a web server that doesn't know anything about sessions.
Personally I don't use sessions in my applications. I simply disable them:
<sessionState mode="Off"></sessionState>
and use standard HTTP artifacts such as cookies, query string parameters, ... to maintain state. I prefer to persist information in my backend and retrieving it later using unique ids instead of relying on sessions.
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 was told this works, but...
I guess I'm just not getting this, it seems there's a hidden step I may be missing, can anyone correct this or point out my mistake? Thanks.
I have a blank solution:
- inside is two .net 2.0 web applications
1) webapp1
2) webapp2
I want them to share the same session data.
My page setups:
Application 1:
Session("value") = "this is the value"
Application 2:
If Not (Session("value") Is Nothing) Then
value = Session("value").ToString()
End If
My thought process:
1) go to services, turn on the asp.net state service
2) open the web configs in both projects: set the
< machineKey
validationKey="BFE2909A81903BB303D738555FEBC0C63EB39636F6FEFBF8005936CBF5FEB88CE327BDBD56AD70749F502FF9D5DECF575C13FA2D17CA8870ED21AD935635D4CC"
decryptionKey="2A86BF77049EBA3A2FA786325592D640D5ACD17AF8FFAC04" validation="SHA1" />
< sessionState mode="StateServer" stateConnectionString="tcpip=localhost:42424"
cookieless="false" timeout="20"/>
in both sites.
3) compile and test the site
4) become disappointed because it does not work. I never see the session from the second webapp.
You cannot share sessions between different ASP.NET applications without some custom code. What you did in web.config was to use an out of process sessions, which means that data will no longer reside into memory but into the memory of a dedicated machine. This is useful for server farms and it uses the ApplicationName to know which application the session belongs to. So basically your applications need to have the same name if you want them to share sessions. There are some dirty workarounds though.
Why do you want to share Sessions between applications? ASP.NET Session is not designed to do that.
Your proposed solution of using the same ASP.NET State Server does not work because your user will simply get 2 different session tokens, even if they use your 2 applications concurrently from the same machine, and same browser. You need to consider how Session works to understand why this is.
From MSDN:
ASP.NET session state enables you to store and retrieve values for a
user as the user navigates ASP.NET pages in a Web application. HTTP is
a stateless protocol. This means that a Web server treats each HTTP
request for a page as an independent request. The server retains no
knowledge of variable values that were used during previous requests.
ASP.NET session state identifies requests from the same browser during
a limited time window as a session, and provides a way to persist
variable values for the duration of that session.
ASP.NET Session is a metaphor for a user's current interaction with one ASP.NET application. It exists in ASP.NET to give us a place to store temporary state data between the various page requests that a user makes while using your application.
If your applications are very closely related, e.g. the user uses both at the same time, or almost the same time, you could consider merging them into a single ASP.NET application. You could deploy them into different Virtual Directories to maintain some degree of logical separation, but use only one Application in IIS.
If your applications are not that closely related, perhaps they should be sharing the same database as a means to exchange data, or using an API e.g. based on Web Services to exchange information.
They will share session data if they are in the same app pool and the session mode is set to inproc. The way that stateserver and sqlstate work is they use the root of your web address as logical boundaries.
Eg if they are both hosted on the same address and port (or 'site' in iis) but in different sibfolders then they should share session I think.
Additionally both apps must run on the same domain so that user browser use one cookie to store session id.
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.