I know the range for Session Timeout is 1-9999, default to (10 or 600?).
My web.config sets SessionState timeout="5"
I have some Razor injecting JavaScript with #Session.Timeout
The Razor evaluates to 5 as expected, everywhere that I can troubleshoot.
Except in Production. If I view the HTML of my production website, the place where the Razor #Session.Timeout sits shows 9999!!?
The Web.Config on the Build-Server shows SessionState timeout="5", and that Web.Config is copied directly to the prod location(s) in automated builds (which I don't have access to.)
Lastly: There are precisely zero calls in the code to alter HttpSessionState.Anything.
What could be the cause?
something overwrite your application web.config
can you check the config files that come before and after your web.config
first one would be the Machine.config systemroot\Microsoft .NET\Framework\versionNumber\CONFIG\Machine.config
second one would be ApplicationHost.config %windir%\system32\inetsrv\config
and third the root Web.config systemroot\Microsoft .NET\Framework\versionNumber\CONFIG\Web.config
also you should check Tip 2: Understand how your site Web.config inherits its settings that simplified it
Some things to check/try:
Check the ApplicationHost.config file to see if session timeout is being defined there.
If you are using forms authentication check this section and see if there is a value out of place:
<authentication mode="Forms">
<forms timeout="9999" ... />
</authentication>
Is anything clever going on in Session_Start in global.asax? Some people like to play around with the session here when it first starts.
Related
I have a .NET application with all the aspx pages and the main web.config in the root folder but I now have a situation where I need a portal like section for other users. I have created a new folder with it's own unique aspx pages and a second web.config.
I especially need a second web.config to have the <authentication> with a <forms loginUrl="" defaultUrl="> for this portal section and a <authentication> too.
I have implemeted this second web.config in the way I created the first and I am getting this error message:
It is an error to use a section registered as allowDefintion='MachineToApplication'
beyond application level. This error can be caused by a virtual directory not being
configured as an application in IIS.
Now I think the main web.config file is conflicting with the this second webconfig in it's folder. I'm not sure how to fix this, I have seen theories on how this works but no solid code.
Thank you for any suggestions and your time, it is much appreciated.
In IIS, create a virtual directory, under your main application. The local web.config will overide stuff in your main web.config, but still use you main web.config for everything else (i.e. ConnectionStrings, encoding, etc.).
I have a custom session provider that stores data in a DB, so fetching session state is not a cheap operation. I have also runAllManagedModulesForAllRequests="true" in my web.config, so sessions are inicialized for every request to an image.
So, I am striving for turning off session state for directories with static resources. Unfortunately, setting <sessionState mode="Off" /> for a folder does not work as this is application-level option.
I could handle this in the code of my custom session provider, but I am wondering if there is some cleaner, more declarative solution.
Edit: <pages enableSessionState="false" /> does not seem to help as it is probably related to ASP.NET pages and controls only.
I don't think that is possible, think about it as session is provided for the whole application, and you just can say at this folder i have and at that i don't, all you can do is to custom code the costly operation of your provider to not run according to certain conditions, place that correctly in your page life cycle.
I ran into the same problem trying to do WebServices with cookieless sessions. I solved it with using a symbolic link. Here are the steps:
1) Make your subdirectory its own application in IIS
2) put this in the subdirectory web.config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<sessionState mode="Off" />
</system.web>
</configuration>
3) Create a symbolic link to redirect BIN to your own BIN. In my example the subdirectory was only 1 level below my main application. So I did this command from the subdirectory:
mklink /D bin ..\bin
That's it. It will load assemblies from your main BIN directory, and inherit all its other settings from your main application.
So I have something weird going on and i can not pin down exactly what is causing it. My asp.net project is live with session state on two production servers that are synced using the following command:
msdeploy -verb:sync -source:webserver,computername=%MACHINE%,username=Administrator,password=%PASSWORD% -dest:webserver 2<&1
The application is an asp.net 4.0 website that is run on two Server 2008 R2 web servers behind a load balanced configuration where the users are set to stick to one server once they connect. We have <MachineKey> set hardcoded with validation and decryption keys in the root site of the application and it is the same between both servers. My application is set up to forward exception events to our email system.
What is happening is that i am receiving the dreaded 'Validation of viewstate MAC failed' from the servers but even though the server load is 50/50 split the errors are coming in on a 99/1 split. So one web server is generating these errors considerably more often than the other one. This is strange considering the servers are synced and all configurations are identical.
I've done extensive searching on this problem and it seems quite difficult to find any solution that doesn't mention or do the following.
<MachineKey> is not identical between servers. (I know for a fact this is not my problem)
Setting enableViewStateMac=false or some other setting that jeopardizes the site security.
Make sure that all action tags on form inputs reference the same page they are placed on
Make sure the instance ID of the servers are the same (they are)
If the user clicks through the page before the entire page (viewstate) has been downloaded (my viewstate is set to render at the top of the page).
Issues with response.redirect and server.transfer
Now i have eliminated all except the last two as possible causes. My application has been running fine for over a year with no issues and right before these errors appeared i enabled SQL session state, migrated the project from .NET 3.5 to .NET 4.0, and set the set the server mode deployment mode to retail. I have tried recycling the application pools and performing an 'iis reset' to no avail.
Does anyone else have any suggestions as to what i can look at? Bottom line i do NOT want to fix this by opening up security holes in my site.
It appears this is happening to users right after they authenticate using forms authentication the first time they try to log in but i can not confirm this. I also have a theory that this might have to do with caching but i can't be sure on this either.
Here is the juicy bit from my web.config (i have removed some sensitive information)
<system.web>
<httpRuntime requestValidationMode="2.0"/>
<globalization culture="en-US" uiCulture="en-US" resourceProviderFactoryType="WebResourceFactory"/>
<compilation debug="true" defaultLanguage="c#" explicit="true" strict="true" targetFramework="4.0">
<assemblies>
</assemblies>
</compilation>
<authentication mode="Forms">
<forms name=".ASPXAUTH" loginUrl="Login.aspx" protection="All" slidingExpiration="true"/>
</authentication>
<authorization>
<deny users="?"/>
</authorization>
<sessionState mode="SQLServer" sqlConnectionString="connection" compressionEnabled="true" />
<pages theme="Blue" controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID">
<machineKey validationKey="key" decryptionKey="key" decryption="3DES" validation="SHA1" />
</system.web>
EDIT:Emphasized that i'm using SQL session state with a load balancer set to prefer to route users to the server they started on.
There is an additional possibility that you have not added to your list - ViewStateUserKey.
I have seen issues with applications where the ViewStateUserKey was set to the Session ID on logon and (crucially) before any data is saved to the Session. Since ASP.NET does not persist Session IDs until one or more objects are saved to session this meant that the ID was constantly changing and the Viewstate was failing validation. Even if you have saved something to Session then the Session will be different on each server if you are using the default in-process model and not a state server or SQL session store (as you are doing). Any server specific value or value that is not readily predictable across servers used with ViewStateUserKey will of course also cause this problem.
Otherwise the most common causes of this issue I have seen is where an "Action" attribute is set on a form that is not the URL of the same page as the form (this catches out developers used to PHP or platforms that do not attempt to abstract away from HTTP), or missing Machine Key attributes in the Web.config in multi-server environments (which you seem to have covered).
Ok i appear to have fixed it, though i can not discern what exactly caused it so i will just list all the steps i performed in case someone else has this problem later on.
1 :
Installed these windows updates:
2:
My forms authentication cookie was set to persistent but my session cookie was set to the browser session. I set my forms authentication cookie to be browser session based.
3:
I copied my from the site config to the root of IIS. From all the documentation i could find it should not be necessary for me to do this because IIS should support multiple machine keys for different sites / applications.
4:
Rebooted the server.
That's it! I have not received the errors since then.
if it is cached, what happens if I use multiple web.config in multi-level folders
They all get cached.
Configuration is read once, at startup. With web.config, IIS watches for file changes and restarts the application.
OK, so ya'll are missing a KEY feature in the Web.Config file's area.
Yes, web.config is cached and changing contents of the file will restart your web app. And, all your connected users will not be happy, too, because they'll need to "reconnect" a-new, possibly losing desired information.
So, use an EXTERNAL custom file for your AppSettings, as follows:
<appSettings configSource="MyCustom_AppSettings.config"/>
Then, in the file MyCustom_AppSettings.config file, you have your settings, as such this example has:
<appSettings>
<!-- AppSecurity Settings -->
<add key="AppStatus_Active" value="Active"/>
<!-- Application Info Settings -->
<add key="AppID" value="25"/>
<add key="AppName" value="MyCoolApp"/>
<add key="AppVersion" value="20120307_162344"/>
</appSettings>
Now, if you need to add, change, or remove an AppSetting, when you change it in this file the change is nearly instant in your web-app BUT (and here's the BEST part), your app DOES NOT RESTART!
Everything stays kosher except those settings you've added/modified/removed in the external .config file.
And, yes, the same thing can done for the section as follows:
<connectionStrings configSource="MyCustomApp_ConnectionStrings.config"/>
and the file MyCustomApp_ConnectionStrings.config has all the connection strings you need. Change a connection string in the external .config file and it starts getting used right away and with no web-app restart.
The configSource setting(s) are great when you need to deploy to development, testing, and production on different boxes and need settings pertinent to that given box/environment.
So, now ya know (something that's been around for 7+ years).
It's That Simple. Really.
KC
Web.config (excluding external config files) is read when the application loads. Some config settings have a cascading behavior. For example, the system.web/authorization section can be overridden by configs at deeper levels.
ASP.NET monitors the web.config for changes. When it changes, the web application is forced to restart. Moral is that web.config settings are cached for the life of the application.
Is it possible to change the web.config file without giving all the users on the site a new session?
You can move the volatile portions of the web.config into external files and then set up IIS to not restart applications when those files change.
In the example below, application and connection-string settings have been moved to another file, outside of the web.config.
<?xml version="1.0"?>
<configuration>
<appSettings configSource="appSettings.config"/>
<connectionStrings configSource="connections.config"/>
</configuration>
Once that's done, you can make changes to app settings (or whatever else you put in the external file) without editing the web.config.
You can also visit the machine.config and play with the restartOnExternalChanges attribute, but this should be used with caution as it could have unintended consequences. Some sections, such as app-settings, already have this set to "false".
<section name="appSettings" restartOnExternalChanges="false">
More details are available in this OdeToCode article.
If you don't use InProc session state, then your sessions should persist across application restarts.
sessionState Element (Including notes on configuring SqlServer mode.