views:

8295

answers:

10

Without routing, HttpContext.Current.Session is there so I know that the StateServer is working. When I route my requests, HttpContext.Current.Session is null in the routed page. I am using .NET 3.5 sp1 on IIS 7.0, without the MVC previews. It appears that AcquireRequestState is never fired when using the routes and so the session variable isn't instantiated/filled.

When I try to access the Session variables, I get this error:

base {System.Runtime.InteropServices.ExternalException} = {"Session state can only be used when enableSessionState is set to true, either in a configuration file or in the Page directive. Please also make sure that System.Web.SessionStateModule or a custom session state module is included in the <configuration>.

While debugging, I also get the error that the HttpContext.Current.Session is not accessible in that context.

--

My web.config looks like this:

<configuration>
  ...
  <system.web>
    <pages enableSessionState="true">
      <controls>
        ...
      </controls>
    </pages>
    ...
  </system.web>
  <sessionState cookieless="AutoDetect" mode="StateServer" timeout="22" />
  ...
</configuration>

Here's the IRouteHandler implementation:

public class WebPageRouteHandler : IRouteHandler, IRequiresSessionState
{
    public string m_VirtualPath { get; private set; }
    public bool m_CheckPhysicalUrlAccess { get; set; }

    public WebPageRouteHandler(string virtualPath) : this(virtualPath, false)
    {
    }
    public WebPageRouteHandler(string virtualPath, bool checkPhysicalUrlAccess)
    {
        m_VirtualPath = virtualPath;
        m_CheckPhysicalUrlAccess = checkPhysicalUrlAccess;
    }

    public IHttpHandler GetHttpHandler(RequestContext requestContext)
    {
        if (m_CheckPhysicalUrlAccess
            && !UrlAuthorizationModule.CheckUrlAccessForPrincipal(
                   m_VirtualPath,
                   requestContext.HttpContext.User,
                   requestContext.HttpContext.Request.HttpMethod))
        {
            throw new SecurityException();
        }

        string var = String.Empty;
        foreach (var value in requestContext.RouteData.Values)
        {
            requestContext.HttpContext.Items[value.Key] = value.Value;
        }

        Page page = BuildManager.CreateInstanceFromVirtualPath(
                        m_VirtualPath, 
                        typeof(Page)) as Page;// IHttpHandler;

        if (page != null)
        {
            return page;
        }
        return page;
    }
}

I've also tried to put EnableSessionState="True" on the top of the aspx pages but still, nothing.

Any insights? Should I write another HttpRequestHandler that implements IRequiresSessionState?

Thanks.

A: 

It seems that you have forgotten to add your state server address in the config file.

 <sessionstate mode="StateServer" timeout="20" server="127.0.0.1" port="42424" />
Bogdan Maxim
Tried it but still the same. It shouldn't really matter w/ its default value:"tcpip=loopback:42424"(http://msdn.microsoft.com/en-us/library/system.web.configuration.sessionstatesection.stateconnectionstring.aspx)I doubt the problem is in the Session provider since it works without the routing.
Loki
A: 

The config section seems sound as it works if when pages are accessed normally. I've tried the other configurations suggested but the problem is still there.

I doubt the problem is in the Session provider since it works without the routing.

Loki
A: 

What @Bogdan Maxim said. Or change to use InProc if you're not using an external sesssion state server.

<sessionState mode="InProc" timeout="20" cookieless="AutoDetect" />

Look here for more info on the SessionState directive.

tvanfosson
SessionState works if I access the page normally. If I use routing, HttpContext.Current.Session is null. The <sessionState> section seems to be working in the config.
Loki
A: 

I think this part of code make changes to the context.

 Page page = BuildManager.CreateInstanceFromVirtualPath(
                        m_VirtualPath, 
                        typeof(Page)) as Page;// IHttpHandler;

Also this part of code is useless:

 if (page != null)
 {
     return page;
 }
 return page;

It will always return the page wither it's null or not.

mnour
Thanks for reminding me. That was some vestigial code after trying out so many things. :D
Loki
+11  A: 

Got it. Quite stupid, actually. It worked after I removed & added the SessionStateModule like so:

<configuration>
  ...
  <system.webServer>
    ...
    <modules>
      <remove name="Session" />
      <add name="Session" type="System.Web.SessionState.SessionStateModule"/>
      ...
    </modules>
  </system.webServer>
</configuration>

Simply adding it won't work since "Session" should have already been defined in the machine.config.

Now, I wonder if that is the usual thing to do. It surely doesn't seem so since it seems so crude...

Loki
Thanks for this. It solved my problem nicely - as it turns out, the production server needed it but not the dev machine.
Raithlin
A: 

Nice job! I've been having the exact same problem. Adding and removing the Session module worked perfectly for me too. It didn't however bring back by HttpContext.Current.User so I tried your little trick with the FormsAuth module and sure enough, that did it.

<remove name="FormsAuthentication" />
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule"/>
Mike
+8  A: 

Just add attribute runAllManagedModulesForAllRequests="true" to system.webServer\modules in web.config.

This attribute is enabled by default in MVC and Dynamic Data projects.

gandjustas
Awesome! this is the answer i was after .. much better than the accepted one.
Pure.Krome
A: 

Thanks Loki and gandjustas!

I was with the same problem (session state works great with "normal" urls, like "http://localhost/Contact.aspx". But was broken with ASP.NET Routing, like "http://localhost/suport/contact").

Both your approachs worked fine.

But I think saw some performance lack with the gandjustas solution (runAllManagedModulesForAllRequests = true).

How this can happen? Strange...

Do have anybody which saw some performance problem using this property?

+3  A: 

a better solution is

runAllManagedModulesForAllRequest is a clever thing to do respect removing and resinserting session module.

alk.

Alkampfer