I have two host in tomcat:
<Host name="host1.domain.com" .../>
<Host name="host2.domain.com" .../>
I found that when i login host1,which will save a "USER_ID" in session,host2 could also get a "USER_ID" in session.
Does it mean tomcat7 will sharing session under a ?
Then how to disable it, i don't want them share the session.
Each webapp has its own set of sessions that do not overlap with any other webapp. Even if the same webapp has been deployed twice (once under host1 and once under host2), they are considered distinct and the sessions will not be shared.
Related
I add value to my session object in Outlook web addin
but my different controller session object is null
Attempted Solutions
I set the following in my web config
<sessionState mode="InProc" timeout="20" />
I set the following in my web config
<remove name="Session" />
<add name="Session" type="System.Web.SessionState.SessionStateModule"/>
Other Items I've tried
Made sure wasn't in the web.config
Tried enabling and running with SSL
Running in release mode
Ensured no Session.Abandon(); or Session.Clear();
Made sure no virus scans were running
Did a search to make sure I wasn't updating elsewhere
Ensured my ASP.NET State Service was running
Tried adding in [WebMethod(EnableSession = true)]
I've ensured I have cookies enabled
I have the following configuration in tomcat configuration files :
<session-config>
<session-timeout>10</session-timeout>
<cookie-config>
<domain>myapp.mycompany.com</domain>
<http-only>true</http-only>
<secure>false</secure>
</cookie-config>
<tracking-mode>COOKIE</tracking-mode>
<Context path=""
docBase="ROOT"
sessionCookieName="mycookiename"
sessionCookieDomain="myapp.mycompany.com"
sessionCookiePath="/"
useHttpOnly="true"
reloadable="false">
<WatchedResource>WEB-INF/web.xml</WatchedResource>
</Context>
As configured above , the cookie is getting set as "session only" in browser ..and on browser quit its getting deleted as expected. But when I am opening the browser again and hitting my application URL again, same JSESSIONID is getting written to the cookie.
Why is it behaving that way ? Isn't it supposed to write a new jsessionid every time ?
It finally appears that the issue was that in Mac i have to actually quit the browser, rather than hitting its close button ...
I have a asp.net MVC 3.0 website hosted on a subdomain of a main website . Asp.net version is set to .Net 4.0 integrated pipeLine .
the Forms Authentication settings is as below :
<authentication mode="Forms">
<forms
cookieless="UseCookies"
defaultUrl="~/home"
enableCrossAppRedirects="false"
path="/"
requireSSL="false"
loginUrl="~/account/login"
protection="All"
timeout="120"
slidingExpiration="true"
name=".SubDomainAuthCookie"></forms>
</authentication>
but it logs me out just after few minutes each time ! the Host Admins say that is maybe because of improper coding or heavy tasks that cause the application pool to reset , but it's a simple mvc website with EF ORM . I can't figure out what to do ! what should I look for as possible cause of this situation ?
Update :
after checking Application_Start , I find that it's the problem , I logged Application_Start() and the result is whenever I'm being logged out , a log is added .
12/6/2012 12:14:03 PM ==> Application started
12/6/2012 12:16:35 PM ==> Application started
12/6/2012 12:22:59 PM ==> Application started
strange ,but real . there is nothing complicated or heavy in the logic ! Could EF be the problem , does it consume a lot of memory/CPU that cause application pool to reset ?
Check there's no other application using name=".SubDomainAuthCookie". These applications can overwrite their cookies.
Are you using FormsAuthentication.SetAuthCookie before calling FormsAuthentication.RedirectFromLoginPage in login page? If not, probably authentication cookies are not set properly.
Try to log Application_End of global.asax.cs to know if your app is recycling too much.
protected void Application_End(object sender, EventArgs e)
{
/log the Application_End/
}
As mentioned by #ZippyV in one of the answers below, the reason behind this is that IIS is by default set to automatically generate a pair of keys for decryption and validating authorization cookie contents (as well as other things) on each AppPool recycle called MachineKey. Also mentioned in this question
When this key is changed, stored authorization cookie contents on all browsers is no longer readable and authorization is lost.
The most simple remedy is to use a static MachineKey in your web.config
Also try to set the cookies to be the parent domain. more info here.
I had this problem too when my hosting provider recycled my site's process too often. For some reason the authentication cookie becomes invalid because the encryption/decryption keys change. And so your site is not able to read the authentication cookie anymore.
You can solve this problem by specifying the keys in your web.config so that they can't get changed by your hosting provider:
Go to http://aspnetresources.com/tools/machineKey and click the button
Copy the generated tag
Open your web.config file and paste the generated tag inside <system.web>
You also want to set the expire time of cookie which has been generated while you log in.
And in form authentiction you have to use this.
FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1, //Here Userinformation, DateTime.Now, DateTime.Now.AddDays(1), false, string.Empty);
Here i have set the expire of cookie to DateTime.Now.AddDays(1) (loggin date+1day) so its too long it will be logged in.
So the created ticket will be expired on next day from when you logged in.
And in Web.Config
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn" timeout="2880" />
</authentication>
Now for a long time you can be logged in.
Hope it helps!!!
Check these links for deeper clarification on create loggin and expire time.
http://www.hanselman.com/blog/WeirdTimeoutsWithCustomASPNETFormsAuthentication.aspx
And
http://codeasp.net/blogs/vivek_iit/microsoft-net/848/forms-authentication-timeout-vs-session-state-timeout
Have you checked value in SessionState? It's default value is 20 Mins. You need to update it to same or greater than form authentication ticket.
Please add/update following tag in your configuration file.
**<sessionState timeout="120" />**
I need to reset the session identifier once user logs in to the application. But I have tried for several days, but still cannot reset jsessionid cookie and if it does, the server seems not recognize it. Could someone please provide some suggestion or some code examples?
Here is the code in login_action.cfm where login.cfm submit the form to:
login form submit user credential to login_action.cfm. here is the code in login_action.cfm:
<cfcookie name="JSESSIONID" value="0" expires="now">
<cfif IsDefined('cookie.JSESSIONID')>
<cfheader name="Set-Cookie" value="JSESSIONID=0;expires=#GetHttpTimeString(CreateODBCDateTime(now()))#;path=/;HTTPOnly;secure=true;">
</cfif>
<cfset structclear(session)>
<cfhttp url="loginverify.cfm" method="post" >
<cfhttpparam name="username" value="#form.username#" type="formfield" ><cfhttpparam name="password" value="#form.password#" type="formfield" >
</cfhttp>
<cfset cookieval = "#MID(cfhttp.responseheader['set-cookie'][1], 12, findnocase(";", cfhttp.responseheader['set-cookie'][1])-13)#">
<cfheader name="Set-Cookie" value="#cfhttp.responseheader['set-cookie'][1]#">
<cfset cookie.jsessionid = cookieval>
<cflocation url="myfirstpage.cfm" addtoken="no">
here is the code to authenticate the user in loginverify.cfm:
<!--- authenticate users --->
<!--- if user passed--->
<cfset session.gooduser = true>
<cfset session.userpermission = 1>
but it seems the session variables defined in loginverify.cfm is not recognized in login_action.cfm
.
Any suggestion?
Thanks a lot.
Just wanted to add an updated answer for this discussion. Since the last comments here, Adobe has addressed session fixation automatically within CF.
If you're on CF10, or if you install CF 9.0.2, that includes it.
If you are on 9.0.1 or less (back to 8.0) there is a security hotfix which add it: APSB11-04 (posted 2/8/2011 and updated 3/7/2011).
Note also that the technote for that fix ( http://helpx.adobe.com/coldfusion/kb/security-hotfix-coldfusion-8-8.html ) also mentions a workaround to disable the session fixation protection (and it would apply to those on 9.0.2 and 10 as well):
If you add the following JVM property, -Dcoldfusion.session.protectfixation=false, to the appropriate jvm.config for your CF instance (and restart), it will revert CF back to not adding the session fixation protection (which simply leaves your server as vulnerable to fixation attacks as it had always been).
Of course, most should want the protection, but as it does introduce some problems for some applications (not well-documented, sadly), just know that it is an option to turn it off, if needed.
An updated version of what you're trying to accomplish can be found at:
12Robots.com - Session token rotation REVISITED (wayback link)
However that has the issue of not cleaning up the extra sessions or carrying over any session data that you want to persist.
With session cleanup
You're not going to be able to log the user in and invalidate their session at the same time. You must invalidate their session and then in the next request, log them in. The basic flow would be something like:
Process login form and make sure the user is valid
Create a secure message containing the user credentials and session data to persist
Invalidate the session
Relocate the page to itself, with the secure message in the url
With the new session created for this page request, log the user in using the credentials from the secure message
Step 3 (invalidating the session) can be done as:
<cfscript>
session.setMaxInactiveInterval(1);
getPageContext().getSession().invalidate();
</cfscript>
<cfcookie name="jsessionid" expires="now">
<cfcookie name="cfid" expires="now">
<cfcookie name="cftoken" expires="now">
and then immediately redirect (cflocation) after that, making sure to have addtoken set to false.
You also need to make sure that the secure message is temporal and can't be used more than once. So you'll have additional database action on both sides of the redirect.
That will accomplish what you're after, but probably not as straight forward as you had hoped.
Simple alternate
Another method of preventing session fixation is to simply prevent step 2 in your reference from happening.
At the most simple, if you see jsessionid, cftoken or cfid in the url then cfabort the request. This must be done before the application "kicks in" and sets or processes client cookies. So in Application.cfm it would be done before cfapplication and in Application.cfc it would be done outside of any function (ie where you set "This.name").
You could take this further and strip out the session identifiers and cflocation to the safe url. This could also be done from the web server using mod_rewrite, et al, to stop ColdFusion from ever seeing the harmful url.
There are additional ways for that step 2 to happen, but all that come to mind require either your webserver or the users machine to be compromised, and if that's the case then session fixation is the least of either of your worries.
I have multidomain web application which treats users differently based on URL they use.
I am using Session["data"] to keep information about user and starting this session with Session_Start["data"] in Global.asax.
All works fine but I would like to know what happens after inactivity. After certain time session will timeout. If that happens is Global.asax treating this as new user and will again start Session_Start for this user?
And will Session["data"] get updated with every page load/reload? Or because it starts just once and will timeout in some exact time?
I tried to make this question as clear as possible.
Thanks.
Session will renew/keep-alive everytime the server gets hit by that user.You set the timeout in the web config file and it is a sliding value, so it restarts again everytime there is a server request.
something like this:
<configuration>
<sessionstate
mode="inproc"
cookieless="false"
timeout="20" />
</configuration>
When the session times out, the next time there is a request, the Session_Start will execute. If you are accessing Session[data] from anywhere else in the code, you should check to make sure it is not null as it will throw a NullReferenceException if the session has timed out and you are trying to access it.
A new session starts when a user first visits a .NET URL (like an .aspx page, but not a .html or other static file) on your site. That session lasts until it times out or the application is killed (restarted/crashes/recycled). The default .NET timeout is 20 minutes; so a session will last as long as the user keeps hitting .aspx pages with no breaks longer than 20 minutes.
During that time, you can store information in the Session object that relates to that user. It is essentially a hashtable that you can populate with objects for which you define keys. In your case, you are using Session["data"], but you could use any key you want, really.
However a session, and the data you store in the Session hashtable, is very fragile (see all the ways it can die above). You shouldn't rely on it to keep anything important that can't be reconstructed easily (in Session_Start, for example). So it really serves two roles: maintaining state (so you know it is still the same user from page to page); and as a user-specific cache where you can keep data in memory to do things more quickly.
Session_Start just runs once per session--by definition. If you need to identify a single user over multiple sessions, you will need to use something more permanent like setting your own cookie with a far-future expiration. You can put an ID in such a cookie that lets you know this is user 12345 (in fact, Session_Start is just the place to look for your "permanent" cookie and connect your data about that existing user with this new session).
And if you want to store data about a user that survives multiple sessions, you will have to store that somewhere more permanent--a database being the most obvious solution. When they come back, you can cache some of that data in the Session hashtable--and Session_Start is just the place to do that as well. Hope this helps.
protected void Session_Start(object sender, EventArgs e)
{
// Code that runs when a new session is started
string RootURL = Request.ApplicationPath;
if (!RootURL.EndsWith("/"))
RootURL += "/";
Globals._rootURL = RootURL;
}