Access to Session Variables

Sep 14, 2011 at 12:53 PM

Everything is working great, this is an amazing project you have put together here!

Web Sockets is a whole new way of thinking for me so please forgive me if this is a stupid question...

Is there a way to access the session dictionary like how we access the cookies?

Coordinator
Sep 14, 2011 at 1:13 PM

You should take a look at the aritcle of SuperSocket:

http://supersocket.codeplex.com/wikipage?title=Fetch%20required%20sessions%20from%20AppServer

Sep 14, 2011 at 4:25 PM

Ahhh, I see! Thank you for your help once again! U da man!

Sep 14, 2011 at 6:51 PM

I am not sure this article and I are talking about the same thing. WHen I say Session, I mean the HttpSessionState object accessed through HttpContext.Current.Session["MySessionVariable"].

Session variables are often used to keep track of users in a web site. They are very similar to a cookie.

The documentation you posted is talking about AppSessions, which is a different kind of session.

Right now we can do this...

AppSession.Cookies["myCookie"]

So I was hoping for something like...

AppSession.Session["MySession"]

 

Coordinator
Sep 15, 2011 at 1:08 AM

Oh, it's simple!

You can use AppSession.Items[Key] to store or read the session level variables.

Sep 15, 2011 at 2:35 AM

I paused the execution and looked at the Items and I saw all of the http headers there. I can see the asp.net session id in the cookie from there too! So now I suppose I can use that to look up session values on the web server somehow. I will check into it.

Coordinator
Sep 15, 2011 at 2:39 AM

Yes, it also works as container of http header items, it's not same with asp.net session variables.

It is only for WebSocket session.

 

Sep 16, 2011 at 1:51 PM

Here is what I am thinking, if I need access to a session variable I can get it through making classic requests to an aspx page or a web service and return results to certain users over the web socket connection based on their cookie data. So I guess what I am saying is... not every request needs to run through the web socket server in both directions. We still do have a regular old web server around that can talk to the socket server nicely.