HttpContext.Current.Session ist null, wenn Anforderungen Routing

Question

Ohne Routing, ist HttpContext.Current.Session es so weiß ich, dass der StateServer arbeitet. Als ich meine Route Anfragen HttpContext.Current.Session in der geroutet Seite null. Ich bin mit .NET 3.5 SP1 auf IIS 7.0, ohne die MVC-Vorschau. Es scheint, dass AcquireRequestState nie ausgelöst wird, wenn die Routen mit und so das Session-Variable wird nicht instanziiert / gefüllt.

Wenn ich versuche, die Session-Variablen zuzugreifen, erhalte ich diese Fehlermeldung:

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

Während des Debuggen, erhalte ich auch den Fehler, dass der HttpContext.Current.Session in diesem Zusammenhang nicht zugänglich ist.

-

Meine web.config sieht wie folgt aus:

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

Hier ist die IRouteHandler Implementierung:

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;
    }
}

Ich habe auch versucht EnableSessionState="True" auf der Oberseite der aspx Seiten zu setzen, aber immer noch nichts.

Keine Erkenntnisse? Sollte ich einen anderen HttpRequestHandler schreiben, die IRequiresSessionState implementiert?

Danke.

Answer 1

Haben Sie es. Ganz dumm, eigentlich. Es funktionierte, nachdem ich entfernt und fügte die Session etwa so:

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

Einfach Zugabe wird es nicht da „Session“ arbeitet bereits in der machine.config definiert worden sein soll.

Nun frage ich mich, ob das ist die übliche Sache zu tun. Es scheint doch nicht so, da es so roh scheint ...

Answer 2

Just Attribut runAllManagedModulesForAllRequests="true" hinzufügen in web.config system.webServer\modules.

Dieses Attribut wird standardmäßig in MVC und Dynamic Data-Projekten aktiviert.

Answer 3

runAllManagedModulesForAllRequests=true ist tatsächlich eine echte schlechte Lösung. Dadurch erhöhte sich die Ladezeit meiner Bewerbung um 200%. Die bessere Lösung ist manuell zu entfernen und das Sitzungsobjekt hinzufügen und den Lauf alle verwalteten Module alle zusammen Attribut zu vermeiden.

Answer 4

Keine dieser Lösungen für mich gearbeitet. Ich habe die folgende Methode in global.asax.cs dann Session war nicht null:

protected void Application_PostAuthorizeRequest()
{
    HttpContext.Current.SetSessionStateBehavior(SessionStateBehavior.Required);
}

Answer 5

Nice job! Ich habe genau das gleiche Problem gehabt. Hinzufügen und Entfernen von dem Session-Modul perfekt für mich auch gearbeitet. Es dauerte jedoch nicht zurückbringen, indem HttpContext.Current.User so dass ich Ihren kleinen Trick mit dem FormsAuth Modul versucht, und sicher genug, dass es getan hat.

<remove name="FormsAuthentication" />
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule"/>

Answer 6

Was sagte @Bogdan Maxim. Oder ändern InProc zu verwenden, wenn Sie keinen externen sesssion State-Server verwendet wird.

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

Schauen Sie hier für weitere Informationen über die Session Richtlinie.

Answer 7

Es scheint, dass Sie vergessen haben, zu Ihrem Staat Server hinzufügen Adresse in der Config Datei.

 <sessionstate mode="StateServer" timeout="20" server="127.0.0.1" port="42424" />

Answer 8

Der Config Abschnitt scheint Sound wie es funktioniert, wenn, wenn die Seiten normal zugegriffen werden. Ich habe die anderen Konfigurationen vorgeschlagen versucht, aber das Problem ist immer noch da.

Ich bezweifle, das Problem in dem Session-Provider ist, da es ohne das Routing funktioniert.

Answer 9

Ich denke, dieser Teil des Codes Änderungen an den Kontext.

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

Auch in diesem Teil des Codes ist nutzlos:

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

Es wird immer die Seite zurückkehren Widerrist es null ist oder nicht.

Answer 10

eine bessere Lösung ist

runAllManagedModulesForAllRequests ist eine kluge Sache zu tun Respekt zu entfernen und Session-Modul wieder einsetzen.

alk.

Answer 11

ich einen Verweis auf System.Web.Mvc dll in der Sitzung Adapter fehlt, und das Hinzufügen von denselben das Problem behoben.

Hoffentlich wird es jemand anderes hilft durch gleiches Szenario gehen.