Encrypting and Decrypting web.config sections

Another thing I do infrequently is encrypt and decrypt web.config sections. I end up going back to a script I wrote ages ago to find the command lines.

So just to save time, here they are:

Encrypt a web.config section

“c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe” -pef sectionName sitePath

E.g.,

“c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe” -pef “connectionStrings” “c:\websites\mysite”

Decrypt a web.config section

“c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe” -pdf sectionName sitePath

E.g.,
“c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe” -pdf “connectionStrings” “c:\websites\mysite”

These command lines must be run on the web server and must be run in a console with admin privileges.

“Unable to attach to process. A debugger is already attached.” (VS 2010, Classic ASP)

Situation:

A fellow developer was using Visual Studio 2010 SP1 to debug a classic ASP application.  He attempted to attach to the IIS process, w3wp.exe and received the error message: “Unable to attach to process. A debugger is already attached.”

Data:

He is running Windows 7, 32 bit. (But I reproduced the error on Win7 64 bit.)

He is using IIS 7.5.

Yesterday he installed IE 10 32 bit. (Yesterday I installed IE 10 64 bit.)

We looked in Process Explorer but no debugger was running that we could see.

We tried changing the “Attach to” type in the “Attach to Process” dialog, but it had no effect.

We tried all sorts of things but nothing made any difference.

I found this forum article:  Visual Studio 2010 debugger already attached classic ASP

I tried debugging the same ASP site by attaching to the IIS process, using VS 2012 and it worked perfectly.

Solution:

Use VS 2012 or revert from IE 10 for Win7 to IE 9.

 

My fellow developer is installing VS 2012. (I don’t know why he didn’t do it already – heck, it’s worth it just for that cool Dark Theme.)

I hope that helps anyone hitting this issue.

ASP.NET Timouts (Sessions and App Pools and Auths, Oh My)

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>

References:

ASP.NET Session Timeouts

sessionState Element

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.”

References:

ASP.NET Session Timeouts

Configure Idle Time-out Settings for an Application Pool (IIS 7)

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>

References:

Answer to question about Session Timeout in ASP.NET

forms Element for authentication

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.

References:

ASP.NET Session Timeouts

Configuring Recycling Settings for an Application Pool (IIS 7)

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.

In Web.Config:

<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.

References:

ASP.NET Session Timeouts

httpRuntime Element

In Code:

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

References:

HttpServerUtility.ScriptTimeout Property

Timeout of an ASP.NET page

ASP.NET Session Timeouts

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.

In Web.Config

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=4.0.0.0, Culture=neutral,PublicKeyToken=B77A5C561934E089" />
      <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler,System.IdentityModel.Services, 
      	Version=4.0.0.0, Culture=neutral,PublicKeyToken=B77A5C561934E089">
        <sessionTokenRequirement lifetime="00:20:00"></sessionTokenRequirement>
      </add>
    </securityTokenHandlers>
  </identityConfiguration>
</system.identityModel>

In Code

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

References:

<securityTokenHandlers>

SessionSecurityTokenHandler Class

Summary

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.

ApplicationPoolIdentity where are you?

ApplicationPoolIdentity is the default username you see assigned to an application pool in IIS 7.x. The only trouble with it is that Windows can’t find it when you try to assign permissions to it, such as when you want to read some files in a folder outside of your website.

Open up the Properties dialog on a folder or file and try to add ApplicationPoolIdentity to the user list on the Security tab.  Ain’t gonna happen, Windows can’t find it.

But do not despair, dear reader, the answer is given here: How to assign permissions to ApplicationPoolIdentity account.

The short version: use the name “IIS APPPOOL\DefaultAppPool” and Windows will find it.

It works – I just tried it.

Hope that helps.