Gestern kam eine interessante Kundenanfrage, bezüglich ASP.NET Sessions:
Wir haben drei verschiedene Web-Anwendungen auf einem Webserver und man soll aus den drei vorhanden Anwendungen auf die Session-Objekte einer übergeordneten Anwendung zugreifen können!
Mein erster Gedanke war, dass die Session nicht im Arbeitsspeicher gehalten werden kann, da der Scope des Session Objekts in ASP.NET standardmäßig auf die Anwendung UND den aktuellen Benutzer beschränkt ist. Eine (eher noch unklare) Absicht war also die Session in eine (SQL) Datenbank auszulagern. Das geht mit Hilfe des aspnet_regsql Tools relativ gut.
Aber auch im SqlServer Mode des sessionstate Eintrages der web.config gilt der Scope der Session wie oben beschrieben und man kann nicht anwendungsübergreifend auf das Sessionobjekt zugreifen.
<sessionState mode="SQLServer" cookieless="false" sqlConnectionString="data source=vista-felixr\sqlexpress;Integrated Security=True;Application Name=Test"/>
Der große Trick besteht nun darin den Stored Procedures, die von ASP.NET im Hintergrund aufgerufen werden um die Sessions zu verwalten, vorzumachen es würde sich jeweils um die gleiche Anwendung handeln.
Wie das ganz genau funktioniert hat Alex Cuse in seinem Blog festgehalten:
http://blogs.lessthandot.com/index.php/WebDev/ServerProgramming/ASPNET/sharing-asp-net-session-state-between-we
Er benutzt allerdings ein ASP.NET MVC Applikation, die für manche vielleicht etwas gewöhnungsbedürftig sein könnte. Ich habe die Anwendung auf’s simpelste reduziert und hochgeladen auf:
http://cid-fd4d63530af59c99.skydrive.live.com/self.aspx/.Public/Projekte/ASP.NET/Sharing%20Session%20between%20Applications.zip
Zur Zusammenfassung nochmal die “high-level” Schritte, wie ich vorgegangen bin
1) Zwei Websites erstellen (Website1 speichert Session, Website2 versucht sie auszulesen)
2) Mit aspnet_regsql Session Management im SQL Server aktivieren (genaue Parameter im Blog oben)
3) sessionstate in der web.config auf mode=”SqlServer” und Application Name=”Test” (auch im Blog beschrieben)
4) Änderung an der Stored Procedure wie im Text beschrieben (man muss nur genau lesen was zu tun ist!)
4) Websites als Anwendungen im lokalen IIS erstellen und laufen lassen (durch verschiedene Ports die vom internen Visual Studio Server generiert werden kann es vorkommen, dass eine neue SessionID angelegt wird für den Zugriff auf die 2. Anwendung, dann gibt es natürlich auch immer ein neues Session Objekt!)