Archive for the ‘ASP.NET’ Category
Recently I’ve been looking into encrypting sections of web.config on a couple of web sites that reside on a web farm.
It’s not very difficult (once you figure out how to get around the fact that some of the instructions don’t work) and I’ll write another post on it once I’ve finished implementing it. But there is one major weak point: What happens if you forget the name of the key you are using? Where do you go to find the names of the RSA keys?
You’d think that listing the names of RSA key containers would be simple. After all, they are real easy to create just type:
aspnet_regiis -pc "MyKeys" -exp
(aspnet_regiis can be found in C:\WINDOWS\Microsoft.Net\Framework\v2.0.50727 or higher)
It’s so simple to do and yet if you forget the name you used then finding it again is virtually impossible.
After many, many searches on Google, Bing and DuckDuckGo, I finally found something that will list them. (Surprisingly it was highest on the DuckDuckGo search and that’s how I found it.)
It’s a simple open source app called KeyPal. Download it, open up a command prompt and run it. At start up it gives you a list of user keys, a list of commands and a blank prompt (with no “>” or anything to indicate it’s a prompt). To list machine level key containers just type “LM”, press Enter and there they are!
There is probably something in the bowels of Windows that will also do this, but I couldn’t find it after searching and searching, so kudos to the guys at JavaScience who wrote KeyPal.
I hope this gets onto search engines to help other poor slobs like me find out how to list RSA Key Container names without spending hours hunting.
I just had to extend the timeout for an ASP.NET site and I had to look it up all over again. I don’t extend timeouts very often but when I do I never remember all the places that I may need to make a change. Sadly just changing sessionState in the Web.Config doesn’t always cut it.
So here, for my future use and for anyone else with the same problem, are a list of all the timeout possibilities that I know of in ASP.NET web apps.
Session State – In web.config
Session state timeout is 20 mins by default. To increase it set the timeout attribute on the sessionState element in the web.config.
<system.web> <sessionState timeout="60" /> </system.web>
App Pool Idle Time-out – In IIS
The Application Pool of your web app has an “Idle Time-out (in minutes)” setting in “Advanced Settings” (IIS7) The help text says: “Amount of time (in minutes ) a worker process will remain idle before it shuts down.”
Forms Authentication Timeout – In web.config
Forms authentication uses it own value for timeout (30 min. by default). A forms authentication timeout will send the user to the login page even if the session is still active. The setting is in minutes.
<system.web> <authentication mode="Forms"> <forms timeout="50"/> </authentication> </system.web>
Recycle Worker Process – in IIS
Not really a timeout but it will have that effect. The default is 29 hours, so you will rarely need to change it.
Execution Timeout – in web.config and in code
This is the time allowed for a request to execute before it is shut down. The default is 110 seconds, so it’s plenty long enough for most situations. If you need to make it longer for your entire site then use web.config and if you need to lengthen it for just a specific request then do it in code.
<system.web> <httpRuntime executionTimeout="180" /> </system.web>
If compilation debug is true then the timeout is always about a year (really). This is so your app doesn’t stop handling a request while you are running through the debugger in Visual Studio.
The HttpServerUtility class has a property called ScriptTimeout that allows you to set the timeout for the current request. In ASP.NET and ASP.NET MVC you can get at this property via the Server property of your Page or Controller.
Server.ScriptTimeout = 600; //in seconds
Security Token Handlers – In web.config and code
Here’s another one I just came across (01/20/2014). This can be used to replace the forms authentication timeout.
The “lifetime” attribute in the sessionTokenRequirement element can be used to set the timeout. It uses the format “hh:mm:ss”.
<system.identityModel> <identityConfiguration> <securityTokenHandlers> <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler,System.IdentityModel, Version=22.214.171.124, Culture=neutral,PublicKeyToken=B77A5C561934E089" /> <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler,System.IdentityModel.Services, Version=126.96.36.199, Culture=neutral,PublicKeyToken=B77A5C561934E089"> <sessionTokenRequirement lifetime="00:20:00"></sessionTokenRequirement> </add> </securityTokenHandlers> </identityConfiguration> </system.identityModel>
Classes derived from SecurityTokenHandler have a TokenLifetime property that can be set using a TimeSpan.
tokenHandler.TokenLifetime = new TimeSpan(0, 20, 0); //hh, mm, ss
I think that’s everything. If not please leave a comment and enlighten me 🙂
If you have any other useful links on the subject please leave those too.
A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 – An existing connection was forcibly closed by the remote host.)
Well, that’s a mouthful, isn’t it?
I saw this in our production web site’s log and wondered how serious an issue it is. Our site is ASP.NET MVC 3, using Entity Framework 4.1 for database connectivity.
I dug around and found the best explanations here:
- Michael Aspengren blog post with the same loooong title
- Adapter client throws an exception on performing an operation after the connectivity is restored between the adapter client and the SQL Server database
- Troubleshooting: Connection Forcibly Closed
It’s only appears once in the current log and not at all in the last archived log, so I’m not going to worry about it, yet. But I thought other people might be interested in what it is, what causes it and what to do about it and I wanted to record the explanation sources in case it happens again and I need to do something about it.
I got this error today and it made no sense at all:
The type 'some_class_name' exists in both 'some_temp.dll' and 'some_other_temp.dll'
The only change I’d made was to some css.
Here’s how I got the error: I had made some changes to a particular user control before I figured out that the layout problem was in the css. I didn’t want to lose my changes, just in case I needed them, so I made copies of the ascx file and its designer file. Then I reverted all changes, modified the css and ran the web site – clang! The error happened.
After googling it, shutting down the VS web server, clearing out the temp ASP.NET folder, cleaning the solution in Visual Studio, rebuilding, rebooting, etc., etc., and nothing working, I finally figured it out.
It was the copies of the files. Despite the fact that the copies were NOT part of the project, the VS web server was compiling them. So of course there were classes with duplicate names.
Once the copies were removed the web site ran fine.