• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 496
  • Last Modified:

Are there any known issues with using the ASP.net SessionId embedded in the HubCallerContext RequestCookies in SignalR 2.x?

Hi All!


I've got a question regarding use of data found within the HubCallerContext.

I notice there's a collection of RequestCookies that hang off of the context.
They contain the following:
    [0]: {[culture, Microsoft.AspNet.SignalR.Cookie]}
    [1]: {[__RequestVerificationToken_L0VDSQ2, Microsoft.AspNet.SignalR.Cookie]}
    [2]: {[ASP.NET_SessionId, Microsoft.AspNet.SignalR.Cookie]}
    [3]: {[XxxAuth, Microsoft.AspNet.SignalR.Cookie]}


In our previous implementation of SignalR, we leveraged the SessionId which hung
off of the HttpContext Session. Since use of the Session is no longer supported
in SignalR 2.x, we were forced to look for an alternative.

In doing so, we noticed "ASP.NET_SessionId" in the RequestCookies.
Does anyone know of any issues or restrictions with using it?
Is this a safe option to utilize?


Thoughts?

Thanks,
JohnB
0
jxbma
Asked:
jxbma
1 Solution
 
jxbmaSoftware ConsultantAuthor Commented:
Since I've received absolutely no attention on this one, I'll leave feedback as to what I've found so far.

We've gone ahead and used the SessionId from the Cookie since that's what is available to us. Up to this point we've seen no issues with this approach.

It remains to be seen whether we'll be continue to support this approach with future releases of SignalR
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now