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
LVL 1
jxbmaSoftware ConsultantAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
jxbmaConnect With a Mentor Software 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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.