I am using the openid-selector with DotNetOpenAuth in my MVC 3 app. Whenever I set a session variable and the DotNetOpenAuth sections are in the web.config, my session variables don't stick after a redirect.
I checked the Session.SessionID variable and it is still the same, so I am in the same session (I believe), but when I check the session variables I just set after a redirect they are all set to null.
I haven't seen anyone else with this issue. I am wondering if DotNetOpenAuth just isn't ready for MVC 3 yet. I am using the latest version of DotNetOpenAuth as well.
Here are the relevant portions of the web.config if it helps:
<configSections>
<section name="uri" type="System.Configuration.UriSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
<section name="dotNetOpenAuth" type="DotNetOpenAuth.Configuration.DotNetOpenAuthSection" requirePermission="false" allowLocation="true"/>
</configSections>
<uri>
<idn enabled="All"/>
<iriParsing enabled="true"/>
</uri>
<system.net>
<defaultProxy enabled="true"/>
<settings>
<servicePointManager checkCertificateRevocationList="true"/>
</settings>
</system.net>
<dotNetOpenAuth>
<openid>
<relyingParty>
<security requireSsl="false"/>
<behaviors>
<add type="DotNetOpenAuth.OpenId.Behaviors.AXFetchAsSregTransform, DotNetOpenAuth"/>
</behaviors>
</relyingParty>
</openid>
<messaging>
<untrustedWebRequest>
<whitelistHosts>
<add name="localhost"/>
</whitelistHosts>
</untrustedWebRequest>
</messaging>
<reporting enabled="true"/>
</dotNetOpenAuth>
Updated:
it is happening on my development server, either in IIS, or when I run the ASP.NET development server.
Also, I tried running session in process and out of process using the state server, and it didn't make a difference.
In regards to a new session, I checked the session_start event, and that isn't being called. I also checked the Session.IsNewSession, and that returned false as well. So something is randomly (or maybe not so randomly) deleting my session variables!
Not the best answer, but I figured out that it's the response.redirect that is killing the session variables for some reason.
So I just made it do a javascript redirect instead, the session stays, everything works fine. Still really don't know what the real issue is here, but hey, I don't have all day to figure it out.
Found the issue here (long ago now). Apparently MVC2 didn't care if I had a view for my actions where I just did some processing then a redirect.
However starting in MVC3, after my upgrade, if I didn't have a view for my action, the page registered an error, and once there was an error, the framework did not store the session variables I just set.
So simple fix... add the views and then also make sure there are no errors in the views.
This should work. I have used DotNetOpenAuth with ASP.NET MVC 3 without any issues. You might want to check that your session doesn't expire during the user is on the remote site for authentication. The fact that you are getting the same SessionId doesn't mean that the session hasn't expired. This could also happen if the server restarts the AppDomain.
DotNetOpenAuth certainly doesn't have Session.Abandon or Session.Clear anywhere in its codebase. It seems possible that if you're setting cookies after the redirect has been sent to the client that those cookies would be lost. Session variables aren't typically persisted as cookies individually though, so if you session cookie made it (and apparently it seems to have) then the rest of your state ought to be there.
It would be interesting to dig into this by implementing your own session store and monitoring what's really going on.
Related
We have a .NET Framework web app where we use .ASPAUTH cookie and ASP.NET_SessionId for authenticated user. Our Session.Timeout is set to 60 minutes in the IIS hosted web.config file.
Recently I follow the recommendation of OWASP top 10 to prevent possible information exposure by Disable caching for response that contain sensitive data.
I did this by adding the following in the Web.config file of the web app.
<httpProtocol>
<customHeaders>
<add name="Cache-Control" value="no-cache, no-store" />
<add name="Pragma" value="no-cache" />
<add name="Expires" value="0" />
</customHeaders>
</httpProtocol>
The very next day I start getting call from some users (not all) that they got redirect to the log out page by simply clicking on links in our web application. So I did what naturally comes to me is to roll back that change and off course that complains went a way gradually.
This puzzle me, as I don't know how http response caching directive could lead to invalidating a user session and log them out. Even though I see the issue went away, there is no way for me to confirm that it was due to my roll back of these header values.
I know the Pragma and Expires are from Pre HTTP 1.1 so I plan to add the following back in and see if I have the log out issue again.
<add name="Cache-Control" value="private, max-age=3600, must-revalidate" />
Do you think they are related? I researched around and all I could come up is the cache control really affect how often the user request resource from server. One factor I don't have control over is can something on the user's browser end that when combine with this Cache-Control directive can destroy their authenticated session?
Update: I see this refers briefly at this resource. However, they don't really go into the details.
I am changing session state in:
<sessionState cookieName="myCookieName" />
It changed correctly, but one issue I am facing is default the "ASP.NET_SessionId" is also showing.
I didn't understand what I am going wrong. How can I fix this?
<system.web>
<sessionState cookieName="foo" />
</system.web>
I need only to show a cookie named foo. I don't want to show "ASP.NET_SessionId".
Maybe it's just a cache issue. Try to delete the cookie in the browser.
Then log in again, and see if it appears again...
I know there are a lot of questions on this topic and I have read them all.
I'm using IIS8, .Net 4.5.
Users randomly get an invalid viewstate error, I can't figure it out. Once this happens the only way they can get back into the site is to clear browser cache.
In my web.config I have:
<system.web>
<machineKey validationKey='....key here' decryptionKey='....decrypt key is valid here' validation='SHA1'/>
<!--<hostingEnvironment shadowCopyBinAssemblies="false" />-->
<authentication mode="None" />
<compilation targetFramework="4.5.1" />
<httpRuntime targetFramework="4.5.1" />
...
</system.web>
I'm running on a virtual private server, and I've yet to find a viewstate larger than 9kb.
My application pool is set to restart at 3:00am, once per day.
My page uses update panels, maybe the user is clicking 'back'? But I've seen it happen just visiting the page with no clicking back.
One thing I noticed is I have 3 different sites using the same application pool identity, but the application pools are seperate. There is no machine keys in machine.xml, but only in my web.config.
A couple of possibilities to investigate:
Update panels are changing form field values (which are what is used to compute ViewState), then the page gets POSTed back to the server, where the new values make validation fail. See this post
You have caching enabled (perform a trace of HTTP headers - make sure you don't have dev tools open) which is causing invalid ViewState to be generated w/ UpdatePanel gumming things up.
Are you using Server.Execute anywhere? (see above link for same)
(less likely) Does your "Virtual Private Server" get migrated to different hardware (perhaps without you knowing it)?
For my MVC4 application, run in Azure, I store the sessions in a co-located cache. As described in this How-to that Microsoft provide.
I run two small instances, and everything seems to work fine. I can log in to the application, and I remain logged in when I browse around within the application. So the session seem to work on both instances.
However, when I update the session data something like this:
HttpContext.Current.Session["someVar"] = "new value";
That change only seem to have an effect on the instance that handle that particular request. Now as I browse around the application, sometimes I get the initial value and sometimes I get the updated value.
I haven't made any changes to the web.config, so it looks exactly as it do when it gets added by the Nuget package:
<sessionState mode="Custom" customProvider="AppFabricCacheSessionStoreProvider">
<providers>
<add name="AppFabricCacheSessionStoreProvider"
type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache"
cacheName="default"
useBlobMode="true"
dataCacheClientName="default" />
</providers>
</sessionState>
Do I need to handle sessions in another way when using the Azure cache, or is it something else I'm missing here?
You need to assign an applicationName so that the distributed cache can view the shared state within the same application boundary. See MSDN forum post for reference.
<add name="AppFabricCacheSessionStoreProvider"
type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache"
applicationName="azureMVC4App"
cacheName="default"
useBlobMode="true"
dataCacheClientName="default" />
If you want to share cache state across application boundaries, you need to assign sharedId
got a problem with my asp.net mvc project timing out after only a couple of minutes. It's especially annoying because I've got quite a complex upload and import procedure which falls over when i get logged out. I currently use asp.net membership provider for authentication.
I've tried a few things that I've seen on this site and others but to no avail. Here is what I have so far in the web config:
<location path="Admin/Upload">
<system.web>
<httpRuntime executionTimeout="1200"/>
</system.web>
</location>
<system.web>
<sessionState mode="InProc" timeout="20" cookieless="false" />
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn" timeout="20" />
</authentication>
<add name="ConnectionString" providerName="System.Data.SqlClient" connectionString="Server=SERVERNAME;Database=DBNAME;User Id=USER;Password=PASSWORD;timeout=30;MultipleActiveResultSets=True" />
I was sure it was only a minute before being timed out before I added the sessionstate timeout, then it was upped to 2 mins, but can't be 100%.
I thought about using this:
<lifetime leaseTime="15M"/>
...but not 100% sure how to implement it - anyone had any success with it, or know something else I could try?
Thanks
EDIT: I'm on a cloud hosting solution, but only have a control panel - no access to IIS
UPDATE: I've now tried adding lifetime leasetime and it's not made any difference:
<system.runtime.remoting>
<application>
<lifetime leaseTime="20M" />
</application>
</system.runtime.remoting>
</configuration>
UPDATE 2:
Ok, I've edited the title and the web config values to reflect my latest effort, but I'm still struggling. I spoke to the hosting company who set the connection timeout to 20 minutes. However, it the session ends after 10 mins. Is there anything else I can try?
I'm getting there, but I would like 20 minutes!
The lifetime leasetime tag goes in the application tag.
<application>
<lifetime leasetime = "15M"/>
I've never actually used it but if it is like other timeouts idk if you will need the M at the end. That is pure speculation though. You should also be able to set it to "0" so that its lifetime is "forever"
As for the session timeout that looks like it should be set for 100 minutes. However, it should be inside of your <configuration> tags
EDIT
Completely unrelated to the question kind of. But i like how your runtime execution timeout is "over 9000"
Right, I got a solution to this, but it wasn't what I was expecting.
It turned out I was using the aspnet Membership Provider wrongly. I was using like a previous membership system I worked on and logging in then setting the UserId as a session variable and using that throughout the site. I then discovered that is the incorrect way to use it, and changed it to a combination of User.Identity.IsAuthenticated and Membership.GetUser().ProviderUserKey.
It no longer times out and all is well. Thanks anyway.