The user identity cannot change during an active SignalR connection #1998

Closed
simoneb opened this Issue May 7, 2013 · 47 comments

Comments

Projects
None yet
@simoneb

simoneb commented May 7, 2013

I'm stuck on this error message which I've started to get after upgrading to 1.1.0-beta1.

I've got several hubs that I'm using on the same page. I'm using the AuthorizeAttribute on a hub method requiring specific roles to be assigned to the user (Windows authentication with AD).

I specifically wanted that only one operation on a specific hub required different privileges from the user, but as I understand this is not possible using the same SignalR connection.

After I started to get this error I tried to fix it by requiring the same roles on all hubs I'm using on the page, but this only makes it slightly better as I still keep getting the error. It almost looks like SignalR thinks that the user identity is changing, can it be that applying the AuthorizeAttribute on all hubs issues every time a new auth token and although the user identity is the same the token ends up being different?

Any guidance about how to fix this is appreciated.

@ghost ghost assigned Xiaohongt May 22, 2013

@DamianEdwards

This comment has been minimized.

Show comment Hide comment
@DamianEdwards

DamianEdwards May 22, 2013

Owner

This error should only occur when the auth ticket being used expires or changes while a connection is active. As you're using Windows Auth in this case though I'm not sure what's going on.

@Xiaohongt can you please try and get a repro.

Owner

DamianEdwards commented May 22, 2013

This error should only occur when the auth ticket being used expires or changes while a connection is active. As you're using Windows Auth in this case though I'm not sure what's going on.

@Xiaohongt can you please try and get a repro.

@simoneb

This comment has been minimized.

Show comment Hide comment
@simoneb

simoneb May 22, 2013

Let me know if you need any help reproducing it. The code is part of a larger application so I would need to spend some time to extract it but I can definitely try if you'd find it useful.

simoneb commented May 22, 2013

Let me know if you need any help reproducing it. The code is part of a larger application so I would need to spend some time to extract it but I can definitely try if you'd find it useful.

@ahorsedev

This comment has been minimized.

Show comment Hide comment
@ahorsedev

ahorsedev May 23, 2013

I am getting same error, a lot of them, we are using form authentication. Any help is greatly appreciated.

I am getting same error, a lot of them, we are using form authentication. Any help is greatly appreciated.

@bording

This comment has been minimized.

Show comment Hide comment
@bording

bording May 24, 2013

I just deployed a SignalR hub to my site for the first time yesterday, and I am also seeing a TON of these errors in ELMAH.

I'm using SignalR 1.1.1 and the site is Web Forms and using forms auth.

bording commented May 24, 2013

I just deployed a SignalR hub to my site for the first time yesterday, and I am also seeing a TON of these errors in ELMAH.

I'm using SignalR 1.1.1 and the site is Web Forms and using forms auth.

@simoneb

This comment has been minimized.

Show comment Hide comment
@simoneb

simoneb May 24, 2013

I had a quick look at SignalR source and could not see any obvious
reason why these errors should happen, in fact I have been unable to
reproduce them in a standalone app I built for this purpose. I'll try
to have another look but if someone can come up with a repro that can
be posted here that would help a lot.

2013/5/24, Brandon Ording notifications@github.com:

I just deployed a SignalR hub to my site for the first time yesterday, and I
am also seeing a TON of these errors in ELMAH.

I'm using SignalR 1.1.1 and the site is Web Forms and using forms auth.


Reply to this email directly or view it on GitHub:
#1998 (comment)

Inviato dal mio dispositivo mobile

simoneb commented May 24, 2013

I had a quick look at SignalR source and could not see any obvious
reason why these errors should happen, in fact I have been unable to
reproduce them in a standalone app I built for this purpose. I'll try
to have another look but if someone can come up with a repro that can
be posted here that would help a lot.

2013/5/24, Brandon Ording notifications@github.com:

I just deployed a SignalR hub to my site for the first time yesterday, and I
am also seeing a TON of these errors in ELMAH.

I'm using SignalR 1.1.1 and the site is Web Forms and using forms auth.


Reply to this email directly or view it on GitHub:
#1998 (comment)

Inviato dal mio dispositivo mobile

@ahorsedev

This comment has been minimized.

Show comment Hide comment
@ahorsedev

ahorsedev May 24, 2013

I was able to reduce some of the Error by replace groupname from using User.Name to SessionToken when adding connectionID to Group, this way, only the connections established during the latest active session will get messages broadcasted over them. I am still seeing this error messages caused by user switching browsers or SignalR aborting old user connections.

P.S, we use Form Authentication and we allow user to have one active session, if you log on to IE and then log on using Chome, we will update cookies with new sessionID from Chome, which I think is causing SignalR barking.

I was able to reduce some of the Error by replace groupname from using User.Name to SessionToken when adding connectionID to Group, this way, only the connections established during the latest active session will get messages broadcasted over them. I am still seeing this error messages caused by user switching browsers or SignalR aborting old user connections.

P.S, we use Form Authentication and we allow user to have one active session, if you log on to IE and then log on using Chome, we will update cookies with new sessionID from Chome, which I think is causing SignalR barking.

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl May 24, 2013

Owner

You can add a client side ping to renew the cookie while the signalr connection is active?

Owner

davidfowl commented May 24, 2013

You can add a client side ping to renew the cookie while the signalr connection is active?

@ahorsedev

This comment has been minimized.

Show comment Hide comment
@ahorsedev

ahorsedev May 24, 2013

instead of renewing the cookie, I would like kill the connections? as soon as I see a new sessionId Comes in for the same user, on the server side. Would you please show me how to kill connections belong to old group.

instead of renewing the cookie, I would like kill the connections? as soon as I see a new sessionId Comes in for the same user, on the server side. Would you please show me how to kill connections belong to old group.

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl May 24, 2013

Owner

You can kill the connection by calling stop on the client.

Owner

davidfowl commented May 24, 2013

You can kill the connection by calling stop on the client.

@simoneb

This comment has been minimized.

Show comment Hide comment
@simoneb

simoneb May 25, 2013

I've been able to get more insight into this issue, although not to reproduce it completely (I'm running against the master now, so something might have changed since the release when the problem appeared for the first time).

The PersistentConnection class basically decodes the connection id from the connection token sent by the client. In order to do so it uses user-protected storage, which also means that for this to work correctly the user must always be the same during the whole lifetime of a SignalR connection.

In my case no authentication was required to access the page where the SignalR connection was first established, but one operation of the hubs used on the page (triggered by user action) required authentication, and since you cannot authenticate via SignalR alone I was first doing an Ajax call to a Web API controller requiring authentication, and only in its callback was I then invoking the SignalR hub.

This basically changed the user with which I first established the SignaR connection, leading to this error. Trying to reproduce it now I get a different error though, The connection id is in the incorrect format, which is another check happening right before the same user check, maybe due to changes happened in SignalR, maybe due to something different I'm doing in my repro.

The bottom line is that for some reason in the latest releases SignalR introduced this requirement (likely driven by the use of protected storage) of a user being the same during the whole connection lifecycle, so the only way to satisfy it is to have the same authentication settings on the resource which hosts your SignalR code and in your SignalR connections/hubs.

simoneb commented May 25, 2013

I've been able to get more insight into this issue, although not to reproduce it completely (I'm running against the master now, so something might have changed since the release when the problem appeared for the first time).

The PersistentConnection class basically decodes the connection id from the connection token sent by the client. In order to do so it uses user-protected storage, which also means that for this to work correctly the user must always be the same during the whole lifetime of a SignalR connection.

In my case no authentication was required to access the page where the SignalR connection was first established, but one operation of the hubs used on the page (triggered by user action) required authentication, and since you cannot authenticate via SignalR alone I was first doing an Ajax call to a Web API controller requiring authentication, and only in its callback was I then invoking the SignalR hub.

This basically changed the user with which I first established the SignaR connection, leading to this error. Trying to reproduce it now I get a different error though, The connection id is in the incorrect format, which is another check happening right before the same user check, maybe due to changes happened in SignalR, maybe due to something different I'm doing in my repro.

The bottom line is that for some reason in the latest releases SignalR introduced this requirement (likely driven by the use of protected storage) of a user being the same during the whole connection lifecycle, so the only way to satisfy it is to have the same authentication settings on the resource which hosts your SignalR code and in your SignalR connections/hubs.

@bording

This comment has been minimized.

Show comment Hide comment
@bording

bording May 29, 2013

I've spent some time looking at what my code was doing to cause this exception, and I have found out a few things.

The main way I've found to reproduce it on my site is to have an active connection while logged in, and then click on one of the logout buttons. Then, it depends on what transport method is being used for the connection. If websockets are being used, everything is fine. The socket connection is closed, and then the request for the logout click is issued, and that response clears the auth cookie.

However, if any other transport method is being used, then the order of the requests changes. First, the logout request happens, clearing the auth cookie. Then you can see the connection abort request, which no longer is authenticated, and SignalR throws an exception.

This transport-specific behavior is a bit surprising, since so much of the rest of SignalR is designed in a way to make you not care about the particular method being used. I don't know if there is any way to change the behavior of the other transport methods to match websockets, but I'm guessing it's a limitation of how they work.

If it is something that can't be changed, this does seem like something that needs to be explicitly called out in the documentation somewhere.

EDIT: Looking at the specifics of the original post in this issue, I suppose what I'm talking about here is a little more generic, since it would apply to all scenarios, not just windows auth. Should I create a new issue and repost, or is it ok to keep what I have in this one?

bording commented May 29, 2013

I've spent some time looking at what my code was doing to cause this exception, and I have found out a few things.

The main way I've found to reproduce it on my site is to have an active connection while logged in, and then click on one of the logout buttons. Then, it depends on what transport method is being used for the connection. If websockets are being used, everything is fine. The socket connection is closed, and then the request for the logout click is issued, and that response clears the auth cookie.

However, if any other transport method is being used, then the order of the requests changes. First, the logout request happens, clearing the auth cookie. Then you can see the connection abort request, which no longer is authenticated, and SignalR throws an exception.

This transport-specific behavior is a bit surprising, since so much of the rest of SignalR is designed in a way to make you not care about the particular method being used. I don't know if there is any way to change the behavior of the other transport methods to match websockets, but I'm guessing it's a limitation of how they work.

If it is something that can't be changed, this does seem like something that needs to be explicitly called out in the documentation somewhere.

EDIT: Looking at the specifics of the original post in this issue, I suppose what I'm talking about here is a little more generic, since it would apply to all scenarios, not just windows auth. Should I create a new issue and repost, or is it ok to keep what I have in this one?

@aquamoogle

This comment has been minimized.

Show comment Hide comment
@aquamoogle

aquamoogle May 30, 2013

We are experiencing nearly the exact same problem as boarding described. Most of our clients use IE8 and IE9 which uses the long polling with SignalR. When you click LogOut we end up getting the user changed exception. Any steps for resolution would be greatly appreciated.

We are experiencing nearly the exact same problem as boarding described. Most of our clients use IE8 and IE9 which uses the long polling with SignalR. When you click LogOut we end up getting the user changed exception. Any steps for resolution would be greatly appreciated.

@simoneb

This comment has been minimized.

Show comment Hide comment
@simoneb

simoneb May 30, 2013

I guess that the resolution is to simply kill and re-establish a SignalR
connection whenever you know that the authenticated user changes. This may
either be a small or big change according to how exactly you are using
SignalR in your app. I think it overall makes sense that this is happening,
it would just be nice if it was documented somewhere and not simply
introduced silently across versions.

On Thu, May 30, 2013 at 11:25 PM, Andrew notifications@github.com wrote:

We are experiencing nearly the exact same problem as boarding described.
Most of our clients use IE8 and IE9 which uses the long polling with
SignalR. When you click LogOut we end up getting the user changed
exception. Any steps for resolution would be greatly appreciated.


Reply to this email directly or view it on GitHubhttps://github.com/SignalR/SignalR/issues/1998#issuecomment-18709512
.

simoneb commented May 30, 2013

I guess that the resolution is to simply kill and re-establish a SignalR
connection whenever you know that the authenticated user changes. This may
either be a small or big change according to how exactly you are using
SignalR in your app. I think it overall makes sense that this is happening,
it would just be nice if it was documented somewhere and not simply
introduced silently across versions.

On Thu, May 30, 2013 at 11:25 PM, Andrew notifications@github.com wrote:

We are experiencing nearly the exact same problem as boarding described.
Most of our clients use IE8 and IE9 which uses the long polling with
SignalR. When you click LogOut we end up getting the user changed
exception. Any steps for resolution would be greatly appreciated.


Reply to this email directly or view it on GitHubhttps://github.com/SignalR/SignalR/issues/1998#issuecomment-18709512
.

@DamianEdwards

This comment has been minimized.

Show comment Hide comment
@DamianEdwards

DamianEdwards May 30, 2013

Owner

This has been the case since 1.0.0, it's just that we changed the exception
message in 1.1.0 to be more descriptive.

On Thu, May 30, 2013 at 2:29 PM, simoneb notifications@github.com wrote:

I guess that the resolution is to simply kill and re-establish a SignalR
connection whenever you know that the authenticated user changes. This may
either be a small or big change according to how exactly you are using
SignalR in your app. I think it overall makes sense that this is
happening,
it would just be nice if it was documented somewhere and not simply
introduced silently across versions.

On Thu, May 30, 2013 at 11:25 PM, Andrew notifications@github.com
wrote:

We are experiencing nearly the exact same problem as boarding described.
Most of our clients use IE8 and IE9 which uses the long polling with
SignalR. When you click LogOut we end up getting the user changed
exception. Any steps for resolution would be greatly appreciated.


Reply to this email directly or view it on GitHub<
https://github.com/SignalR/SignalR/issues/1998#issuecomment-18709512>
.


Reply to this email directly or view it on GitHubhttps://github.com/SignalR/SignalR/issues/1998#issuecomment-18709714
.

Cheers,
Damian

Owner

DamianEdwards commented May 30, 2013

This has been the case since 1.0.0, it's just that we changed the exception
message in 1.1.0 to be more descriptive.

On Thu, May 30, 2013 at 2:29 PM, simoneb notifications@github.com wrote:

I guess that the resolution is to simply kill and re-establish a SignalR
connection whenever you know that the authenticated user changes. This may
either be a small or big change according to how exactly you are using
SignalR in your app. I think it overall makes sense that this is
happening,
it would just be nice if it was documented somewhere and not simply
introduced silently across versions.

On Thu, May 30, 2013 at 11:25 PM, Andrew notifications@github.com
wrote:

We are experiencing nearly the exact same problem as boarding described.
Most of our clients use IE8 and IE9 which uses the long polling with
SignalR. When you click LogOut we end up getting the user changed
exception. Any steps for resolution would be greatly appreciated.


Reply to this email directly or view it on GitHub<
https://github.com/SignalR/SignalR/issues/1998#issuecomment-18709512>
.


Reply to this email directly or view it on GitHubhttps://github.com/SignalR/SignalR/issues/1998#issuecomment-18709714
.

Cheers,
Damian

@simoneb

This comment has been minimized.

Show comment Hide comment
@simoneb

simoneb May 30, 2013

Correct, I think I was probably upgrading straight from 1.0 rc2 (which
didn't have it) to 1.1.0.

On Fri, May 31, 2013 at 12:14 AM, Damian Edwards
notifications@github.comwrote:

This has been the case since 1.0.0, it's just that we changed the
exception
message in 1.1.0 to be more descriptive.

On Thu, May 30, 2013 at 2:29 PM, simoneb notifications@github.com
wrote:

I guess that the resolution is to simply kill and re-establish a SignalR
connection whenever you know that the authenticated user changes. This
may
either be a small or big change according to how exactly you are using
SignalR in your app. I think it overall makes sense that this is
happening,
it would just be nice if it was documented somewhere and not simply
introduced silently across versions.

On Thu, May 30, 2013 at 11:25 PM, Andrew notifications@github.com
wrote:

We are experiencing nearly the exact same problem as boarding
described.
Most of our clients use IE8 and IE9 which uses the long polling with
SignalR. When you click LogOut we end up getting the user changed
exception. Any steps for resolution would be greatly appreciated.


Reply to this email directly or view it on GitHub<
https://github.com/SignalR/SignalR/issues/1998#issuecomment-18709512>
.


Reply to this email directly or view it on GitHub<
https://github.com/SignalR/SignalR/issues/1998#issuecomment-18709714>
.

Cheers,
Damian


Reply to this email directly or view it on GitHubhttps://github.com/SignalR/SignalR/issues/1998#issuecomment-18711915
.

simoneb commented May 30, 2013

Correct, I think I was probably upgrading straight from 1.0 rc2 (which
didn't have it) to 1.1.0.

On Fri, May 31, 2013 at 12:14 AM, Damian Edwards
notifications@github.comwrote:

This has been the case since 1.0.0, it's just that we changed the
exception
message in 1.1.0 to be more descriptive.

On Thu, May 30, 2013 at 2:29 PM, simoneb notifications@github.com
wrote:

I guess that the resolution is to simply kill and re-establish a SignalR
connection whenever you know that the authenticated user changes. This
may
either be a small or big change according to how exactly you are using
SignalR in your app. I think it overall makes sense that this is
happening,
it would just be nice if it was documented somewhere and not simply
introduced silently across versions.

On Thu, May 30, 2013 at 11:25 PM, Andrew notifications@github.com
wrote:

We are experiencing nearly the exact same problem as boarding
described.
Most of our clients use IE8 and IE9 which uses the long polling with
SignalR. When you click LogOut we end up getting the user changed
exception. Any steps for resolution would be greatly appreciated.


Reply to this email directly or view it on GitHub<
https://github.com/SignalR/SignalR/issues/1998#issuecomment-18709512>
.


Reply to this email directly or view it on GitHub<
https://github.com/SignalR/SignalR/issues/1998#issuecomment-18709714>
.

Cheers,
Damian


Reply to this email directly or view it on GitHubhttps://github.com/SignalR/SignalR/issues/1998#issuecomment-18711915
.

@mkrisky

This comment has been minimized.

Show comment Hide comment
@mkrisky

mkrisky Jun 3, 2013

We are running in to this issue when a user logs out and is redirected to our openid provider login page. When they log in as a different user, we get the error 'Unrecognized user identity. The user identity cannot change during an active SignalR connection. '. If they log in again as the same user, they are redirected to a blank white page with the URL 'https://www.ourwebsite.com/signalr/abort?transport=foreverFrame&connectionToken=Q0TNImwYY8JrBKna5kvH1omlY0OoA3......'. Everything works fine if they close the browser window. Do I need to manually close the connection in our logout code? If so, how exactly do I do that?

mkrisky commented Jun 3, 2013

We are running in to this issue when a user logs out and is redirected to our openid provider login page. When they log in as a different user, we get the error 'Unrecognized user identity. The user identity cannot change during an active SignalR connection. '. If they log in again as the same user, they are redirected to a blank white page with the URL 'https://www.ourwebsite.com/signalr/abort?transport=foreverFrame&connectionToken=Q0TNImwYY8JrBKna5kvH1omlY0OoA3......'. Everything works fine if they close the browser window. Do I need to manually close the connection in our logout code? If so, how exactly do I do that?

@simoneb

This comment has been minimized.

Show comment Hide comment
@simoneb

simoneb Jun 3, 2013

As explained, you cannot change the user identity during the lifecycle of a
connection. To close the connection you call stop from the client, as
mentioned by David in this issue some time ago.
On Jun 3, 2013 4:13 PM, "mkrisky" notifications@github.com wrote:

We are running in to this issue when a user logs out and is redirected to
our openid provider login page. When they log in as a different user, we
get the error 'Unrecognized user identity. The user identity cannot change
during an active SignalR connection. '. If they log in again as the same
user, they are redirected to a blank white page with the URL '
https://www.ourwebsite.com/signalr/abort?transport=foreverFrame&connectionToken=Q0TNImwYY8JrBKna5kvH1omlY0OoA3......'.
Everything works fine if they close the browser window. Do I need to
manually close the connection in our logout code? If so, how exactly do I
do that?


Reply to this email directly or view it on GitHubhttps://github.com/SignalR/SignalR/issues/1998#issuecomment-18843751
.

simoneb commented Jun 3, 2013

As explained, you cannot change the user identity during the lifecycle of a
connection. To close the connection you call stop from the client, as
mentioned by David in this issue some time ago.
On Jun 3, 2013 4:13 PM, "mkrisky" notifications@github.com wrote:

We are running in to this issue when a user logs out and is redirected to
our openid provider login page. When they log in as a different user, we
get the error 'Unrecognized user identity. The user identity cannot change
during an active SignalR connection. '. If they log in again as the same
user, they are redirected to a blank white page with the URL '
https://www.ourwebsite.com/signalr/abort?transport=foreverFrame&connectionToken=Q0TNImwYY8JrBKna5kvH1omlY0OoA3......'.
Everything works fine if they close the browser window. Do I need to
manually close the connection in our logout code? If so, how exactly do I
do that?


Reply to this email directly or view it on GitHubhttps://github.com/SignalR/SignalR/issues/1998#issuecomment-18843751
.

@stanhuff

This comment has been minimized.

Show comment Hide comment
@stanhuff

stanhuff Jun 3, 2013

I had a case where I was adding SignalR functionality to an existing website. There had been global exception handling setup on the Application class and it was trapping all errors and returning a "friendly" page rather than letting the error pass through. This naturally botched the signalr error return and caused "parseError" jquery ajax errors to happen which are happily ignored by the current implementation of ajaxSend. In this case, my client code had no way of knowing these Identity Changed errors were happening and while I've solved my issue by filtering out the signalr exceptions that are "made friendly", signalr could be made a little more friendly if its ajaxSend were a little more selective about which parseErrors it chose to ignore perhaps by checking the responseText.

stanhuff commented Jun 3, 2013

I had a case where I was adding SignalR functionality to an existing website. There had been global exception handling setup on the Application class and it was trapping all errors and returning a "friendly" page rather than letting the error pass through. This naturally botched the signalr error return and caused "parseError" jquery ajax errors to happen which are happily ignored by the current implementation of ajaxSend. In this case, my client code had no way of knowing these Identity Changed errors were happening and while I've solved my issue by filtering out the signalr exceptions that are "made friendly", signalr could be made a little more friendly if its ajaxSend were a little more selective about which parseErrors it chose to ignore perhaps by checking the responseText.

@elgerm

This comment has been minimized.

Show comment Hide comment
@elgerm

elgerm Jun 11, 2013

I get loads of these errors on my live website (20.000 uniques per day), but can't reproduce it in development. I have 2 load balanced servers with shared configuration and a shared machinekey for forms auth. Could this be the cause?

elgerm commented Jun 11, 2013

I get loads of these errors on my live website (20.000 uniques per day), but can't reproduce it in development. I have 2 load balanced servers with shared configuration and a shared machinekey for forms auth. Could this be the cause?

@stanhuff

This comment has been minimized.

Show comment Hide comment
@stanhuff

stanhuff Jun 11, 2013

These errors happened for me when my session cookie would expire and I was using a transport employing ajax. Once the cookie expires, I started getting tons of errors (one per client request) but my client-side code was unable to see the errors because of an Application_Error handler that was effectively converting the error to a friendly page, even for signalr requests. Allowing the exceptions to propogate out for the requests that were targeting signalr url routes allowed my client code to see the failures and take action.

These errors happened for me when my session cookie would expire and I was using a transport employing ajax. Once the cookie expires, I started getting tons of errors (one per client request) but my client-side code was unable to see the errors because of an Application_Error handler that was effectively converting the error to a friendly page, even for signalr requests. Allowing the exceptions to propogate out for the requests that were targeting signalr url routes allowed my client code to see the failures and take action.

@DamianEdwards

This comment has been minimized.

Show comment Hide comment
@DamianEdwards

DamianEdwards Jul 3, 2013

Owner

Let's fix this by making the JS client automatically ping the server using the existing ping endpoint we added in an earlier release.

The default ping interval should be every 5 minutes. The ping interval should be configurable via the options object passed to connection.start(), e.g.

// Start the connection with a ping interval of 60 seconds (defaults to 300 seconds)
// To disable the ping altogether just set it to any value that isn't a positive integer, e.g. 0, null, undefined, empty string, whatever.
connection.start({ pingInterval: 60});
Owner

DamianEdwards commented Jul 3, 2013

Let's fix this by making the JS client automatically ping the server using the existing ping endpoint we added in an earlier release.

The default ping interval should be every 5 minutes. The ping interval should be configurable via the options object passed to connection.start(), e.g.

// Start the connection with a ping interval of 60 seconds (defaults to 300 seconds)
// To disable the ping altogether just set it to any value that isn't a positive integer, e.g. 0, null, undefined, empty string, whatever.
connection.start({ pingInterval: 60});
@denniske

This comment has been minimized.

Show comment Hide comment
@denniske

denniske Jul 10, 2013

Where can I find documentation about pingInterval?

Is this setting available in SignalR 1.1.2?

Where can I find documentation about pingInterval?

Is this setting available in SignalR 1.1.2?

@NTaylorMullen

This comment has been minimized.

Show comment Hide comment
@NTaylorMullen

NTaylorMullen Jul 15, 2013

Contributor

@denniske it has not been added yet

Contributor

NTaylorMullen commented Jul 15, 2013

@denniske it has not been added yet

NTaylorMullen added a commit that referenced this issue Jul 16, 2013

Added a ping interval on the client to ensure that auth tickets do no…
…t expire when there's lack of activity.

- This also involved adding a new configuration option 'pingInterval' which can be set via seconds

#1998

NTaylorMullen added a commit that referenced this issue Jul 16, 2013

Added tests to verify that pingInterval behaves correctly with differ…
…ent configuration options in addition to multiple connection starts and stops.

#1998

NTaylorMullen added a commit that referenced this issue Jul 22, 2013

Added a ping interval on the client to ensure that auth tickets do no…
…t expire when there's lack of activity.

- This also involved adding a new configuration option 'pingInterval' which can be set via seconds

#1998

NTaylorMullen added a commit that referenced this issue Jul 22, 2013

Added tests to verify that pingInterval behaves correctly with differ…
…ent configuration options in addition to multiple connection starts and stops.

#1998

NTaylorMullen added a commit that referenced this issue Jul 26, 2013

Added a ping interval on the client to ensure that auth tickets do no…
…t expire when there's lack of activity.

- This also involved adding a new configuration option 'pingInterval' which can be set via seconds

#1998

NTaylorMullen added a commit that referenced this issue Jul 26, 2013

Added tests to verify that pingInterval behaves correctly with differ…
…ent configuration options in addition to multiple connection starts and stops.

#1998

@ghost ghost assigned gustavo-armenta Jul 29, 2013

@gustavo-armenta

This comment has been minimized.

Show comment Hide comment
@gustavo-armenta

gustavo-armenta Jul 29, 2013

Contributor

Reviewed this bug and mentioned to handle the concurrency of reconnecting and pinging. Fixes will be made in #2360
Tested ping interval is configurable in connection.start({pingInterval: milliseconds})

Contributor

gustavo-armenta commented Jul 29, 2013

Reviewed this bug and mentioned to handle the concurrency of reconnecting and pinging. Fixes will be made in #2360
Tested ping interval is configurable in connection.start({pingInterval: milliseconds})

@alfeg

This comment has been minimized.

Show comment Hide comment
@alfeg

alfeg Oct 2, 2013

@davidfowl quick question. Is there a way to handle 'The user identity cannot change during an active SignalR connection' error on server side?

I have tried it through HubPipelineModule,OnIncomingError but with no success.
PS: I'm using 1.1.3 version of SignalR

alfeg commented Oct 2, 2013

@davidfowl quick question. Is there a way to handle 'The user identity cannot change during an active SignalR connection' error on server side?

I have tried it through HubPipelineModule,OnIncomingError but with no success.
PS: I'm using 1.1.3 version of SignalR

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Oct 2, 2013

Owner

@alfeg What do you mean handle?

Owner

davidfowl commented Oct 2, 2013

@alfeg What do you mean handle?

@alfeg

This comment has been minimized.

Show comment Hide comment
@alfeg

alfeg Oct 3, 2013

@davidfowl I need ability to catch this exception. And I don't know where I can do it, other than ApplicationError

alfeg commented Oct 3, 2013

@davidfowl I need ability to catch this exception. And I don't know where I can do it, other than ApplicationError

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Oct 3, 2013

Owner

@alfeg Catch the exception and then do what? Log it?

Owner

davidfowl commented Oct 3, 2013

@alfeg Catch the exception and then do what? Log it?

@elgerm

This comment has been minimized.

Show comment Hide comment
@elgerm

elgerm Oct 3, 2013

uncaught_signalr_exceptions
This is a 2 minute event log of a live website with signalr. I think that speaks for itself, they should not be in the log, it's very hard to spot any serious problems like this.

elgerm commented Oct 3, 2013

uncaught_signalr_exceptions
This is a 2 minute event log of a live website with signalr. I think that speaks for itself, they should not be in the log, it's very hard to spot any serious problems like this.

@alfeg

This comment has been minimized.

Show comment Hide comment
@alfeg

alfeg Oct 3, 2013

@davidfowl at least wrap it with our application exception, so that javascript clients can be aware of it, and we can show some fancy windows to them.

For some parts of our app and due to distributed nature of our app we cannot force log out user from other tabs, or event send a message there that cookie has changed. So at least when js client receive error, I would like to wrap it in exception, that recognized by application.

alfeg commented Oct 3, 2013

@davidfowl at least wrap it with our application exception, so that javascript clients can be aware of it, and we can show some fancy windows to them.

For some parts of our app and due to distributed nature of our app we cannot force log out user from other tabs, or event send a message there that cookie has changed. So at least when js client receive error, I would like to wrap it in exception, that recognized by application.

@SteveSyfuhs

This comment has been minimized.

Show comment Hide comment
@SteveSyfuhs

SteveSyfuhs Oct 4, 2013

Part of the problem with this exception is that it's not particularly useful, and it happens in quite a number of normal scenarios. The ping updates don't solve the problem in some cases because it assumes a sliding expiration for the session.

I would also think in this particular scenario this exception should bubble up a HTTP 401/403 because the given identity does not match the expected identity.

It'd be nice to be able to smother the exception server-side so the various exception loggers don't have to deal with it when it's a known condition, e.g. the user logged out and hasn't reconnected.

Part of the problem with this exception is that it's not particularly useful, and it happens in quite a number of normal scenarios. The ping updates don't solve the problem in some cases because it assumes a sliding expiration for the session.

I would also think in this particular scenario this exception should bubble up a HTTP 401/403 because the given identity does not match the expected identity.

It'd be nice to be able to smother the exception server-side so the various exception loggers don't have to deal with it when it's a known condition, e.g. the user logged out and hasn't reconnected.

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Oct 4, 2013

Owner

We have a bug to swallow certain server errors(#2522). I'll add this one to the list.

Owner

davidfowl commented Oct 4, 2013

We have a bug to swallow certain server errors(#2522). I'll add this one to the list.

@niemyjski

This comment has been minimized.

Show comment Hide comment
@niemyjski

niemyjski Mar 5, 2014

I'm still seeing this issue with the latest version of SignalR:

System.InvalidOperationException: Unrecognized user identity. The user identity cannot change during an active SignalR connection.
at Microsoft.AspNet.SignalR.PersistentConnection.GetConnectionId(HostContext context, String connectionToken)
 at Microsoft.AspNet.SignalR.PersistentConnection.ProcessRequest(HostContext context)
 at Microsoft.AspNet.SignalR.Hubs.HubDispatcher.ProcessRequest(HostContext context)
 at Microsoft.AspNet.SignalR.PersistentConnection.ProcessRequest(IDictionary`2 environment)
 at Microsoft.Owin.Mapping.MapMiddleware.d__0.MoveNext()
 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 at Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.IntegratedPipelineContext.EndFinalWork(IAsyncResult ar)
 at System.Web.HttpApplication.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
 at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

I'm still seeing this issue with the latest version of SignalR:

System.InvalidOperationException: Unrecognized user identity. The user identity cannot change during an active SignalR connection.
at Microsoft.AspNet.SignalR.PersistentConnection.GetConnectionId(HostContext context, String connectionToken)
 at Microsoft.AspNet.SignalR.PersistentConnection.ProcessRequest(HostContext context)
 at Microsoft.AspNet.SignalR.Hubs.HubDispatcher.ProcessRequest(HostContext context)
 at Microsoft.AspNet.SignalR.PersistentConnection.ProcessRequest(IDictionary`2 environment)
 at Microsoft.Owin.Mapping.MapMiddleware.d__0.MoveNext()
 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 at Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.IntegratedPipelineContext.EndFinalWork(IAsyncResult ar)
 at System.Web.HttpApplication.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
 at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Mar 5, 2014

Owner

Are you using sliding or absolute expiration?

Owner

davidfowl commented Mar 5, 2014

Are you using sliding or absolute expiration?

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Mar 5, 2014

Owner

Actually, looking at your callstack, it seems you're not using the latest version. That method doesn't exist in 2.0.2

Owner

davidfowl commented Mar 5, 2014

Actually, looking at your callstack, it seems you're not using the latest version. That method doesn't exist in 2.0.2

@niemyjski

This comment has been minimized.

Show comment Hide comment
@niemyjski

niemyjski Mar 5, 2014

I'm not sure.. We aren't specifying any thing for expiration.. I'm using 2.0.2.

< package id="Microsoft.AspNet.SignalR" version="2.0.2" targetFramework="net451" />
< package id="Microsoft.AspNet.SignalR.Core" version="2.0.2" targetFramework="net451" />
< package id="Microsoft.AspNet.SignalR.JS" version="2.0.2" targetFramework="net451" />
< package id="Microsoft.AspNet.SignalR.Redis" version="2.0.2" targetFramework="net451" />
< package id="Microsoft.AspNet.SignalR.SystemWeb" version="2.0.2" targetFramework="net451" />

I'm not sure.. We aren't specifying any thing for expiration.. I'm using 2.0.2.

< package id="Microsoft.AspNet.SignalR" version="2.0.2" targetFramework="net451" />
< package id="Microsoft.AspNet.SignalR.Core" version="2.0.2" targetFramework="net451" />
< package id="Microsoft.AspNet.SignalR.JS" version="2.0.2" targetFramework="net451" />
< package id="Microsoft.AspNet.SignalR.Redis" version="2.0.2" targetFramework="net451" />
< package id="Microsoft.AspNet.SignalR.SystemWeb" version="2.0.2" targetFramework="net451" />

@niemyjski

This comment has been minimized.

Show comment Hide comment
@niemyjski

niemyjski Mar 10, 2014

Any ideas why I'm seeing this with 2.0.2?

Any ideas why I'm seeing this with 2.0.2?

@vikcky1228

This comment has been minimized.

Show comment Hide comment
@vikcky1228

vikcky1228 Aug 4, 2014

how to stop signalR server

how to stop signalR server

@SilvioAmaral

This comment has been minimized.

Show comment Hide comment
@SilvioAmaral

SilvioAmaral Aug 15, 2014

Shouldn't we reopen this ? What would be the solution, since it was closed ? I dont think that upgrading to version 2.0 is an acceptable response, due to the fact that not always our servers will have the pre-requisites to run 2.0 (yes, my case).

Can you please provide a fix for this ?

Shouldn't we reopen this ? What would be the solution, since it was closed ? I dont think that upgrading to version 2.0 is an acceptable response, due to the fact that not always our servers will have the pre-requisites to run 2.0 (yes, my case).

Can you please provide a fix for this ?

@PHANTOMER

This comment has been minimized.

Show comment Hide comment
@PHANTOMER

PHANTOMER Mar 22, 2015

I am still experiencing this issue. I have chat application. 2 tabs open in firefox (logged in as 2 different users). When I connect to my hub from the first tab, I am able to send messages. Then, as soon as I start connection from the second tab, the first tab goes crazy. When I try to send the message, I get a lot of 403 errors, which say that identity cannot change during active SignalR connection.

I am still experiencing this issue. I have chat application. 2 tabs open in firefox (logged in as 2 different users). When I connect to my hub from the first tab, I am able to send messages. Then, as soon as I start connection from the second tab, the first tab goes crazy. When I try to send the message, I get a lot of 403 errors, which say that identity cannot change during active SignalR connection.

@Sam-Davis

This comment has been minimized.

Show comment Hide comment
@Sam-Davis

Sam-Davis Jul 22, 2015

I found that this issue was solved by disabling anonymous authentication. Full answer here:
http://stackoverflow.com/a/31564482/2945345

I found that this issue was solved by disabling anonymous authentication. Full answer here:
http://stackoverflow.com/a/31564482/2945345

@niemyjski

This comment has been minimized.

Show comment Hide comment
@niemyjski

niemyjski Jul 23, 2015

@Sam-Davis, but we don't have that enabled to begin with.

@Sam-Davis, but we don't have that enabled to begin with.

@Sam-Davis

This comment has been minimized.

Show comment Hide comment
@Sam-Davis

Sam-Davis Jul 23, 2015

Sure. What type of auth are you using? The issue I was having was basically a race condition. Perhaps, you need to create a promise for the user being connected and only connect to signalR once this is complete.

Sure. What type of auth are you using? The issue I was having was basically a race condition. Perhaps, you need to create a promise for the user being connected and only connect to signalR once this is complete.

@niemyjski

This comment has been minimized.

Show comment Hide comment
@niemyjski

niemyjski Jul 23, 2015

OAuth/Token based authentication

OAuth/Token based authentication

@Zeni241

This comment has been minimized.

Show comment Hide comment
@Zeni241

Zeni241 Aug 10, 2015

I was getting the same error message when the user loggedIn and the user identity changed. The solution is to disconnect the hub connection before logging in and restart the signalR hub connection after successful logging.
The following example shows how to stop and start a connection when the user status has changed.

$(function () {
    var chat = $.connection.sampleHub;
    $.connection.hub.start().done(function () {
        $('#logoutbutton').click(function () {
            chat.connection.stop();
            $.ajax({
                url: "Services/SampleWebService.svc/LogOut",
                type: "POST"
            }).done(function () {
                chat.connection.start();
            });
        });
    });
});

The details can be found here. http://www.asp.net/signalr/overview/security/introduction-to-security

Zeni241 commented Aug 10, 2015

I was getting the same error message when the user loggedIn and the user identity changed. The solution is to disconnect the hub connection before logging in and restart the signalR hub connection after successful logging.
The following example shows how to stop and start a connection when the user status has changed.

$(function () {
    var chat = $.connection.sampleHub;
    $.connection.hub.start().done(function () {
        $('#logoutbutton').click(function () {
            chat.connection.stop();
            $.ajax({
                url: "Services/SampleWebService.svc/LogOut",
                type: "POST"
            }).done(function () {
                chat.connection.start();
            });
        });
    });
});

The details can be found here. http://www.asp.net/signalr/overview/security/introduction-to-security

@psib3r

This comment has been minimized.

Show comment Hide comment
@psib3r

psib3r Jan 18, 2017

I had a similar error when using it in an MVC app, in my controller I had [Authorize] so I could get the user name from the HttpContext, this caused the issue, to resolve I simply added [Authorize] to my Hub class.

psib3r commented Jan 18, 2017

I had a similar error when using it in an MVC app, in my controller I had [Authorize] so I could get the user name from the HttpContext, this caused the issue, to resolve I simply added [Authorize] to my Hub class.

@RasicN

This comment has been minimized.

Show comment Hide comment
@RasicN

RasicN Jan 8, 2018

@psib3r this took me way to long to find. Thanks! That was exactly my problem. Just as a heads up if you are using Chrome as of right now you will not be able to Authenticate using windows authentication and websockets: https://stackoverflow.com/questions/26863242/signalr-mvc-5-websocket-no-valid-credentials.
But putting the [Authorize] tag on my Hub combined with anonymous authentication being enabled and Chrome created some weird things to happen. Thanks!

RasicN commented Jan 8, 2018

@psib3r this took me way to long to find. Thanks! That was exactly my problem. Just as a heads up if you are using Chrome as of right now you will not be able to Authenticate using windows authentication and websockets: https://stackoverflow.com/questions/26863242/signalr-mvc-5-websocket-no-valid-credentials.
But putting the [Authorize] tag on my Hub combined with anonymous authentication being enabled and Chrome created some weird things to happen. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment