6

ASP.NET MVC3 アプリケーションのチャット コアとして SignalR 1.0.1 を使用しています。IIS 7.5 の使用

チャット ビューへのアクセスを提供する MVC コントローラーには 2 つの方法があります
。
2. 2 番目の方法へのアクセスは[Authorize]、ドメイン ユーザー - チャット エージェントの属性で制限されます。

ハブには明示的に指定された承認はありません。
このシナリオでは、IIS で Windows 認証と匿名認証の両方を使用しました。

また、カスタム ロール プロバイダーも実装しました。これはメモリ内でのみ動作し、データベースには何も保持しません。

何が起こるかというと、コントローラー メソッドで '[Authorize]' 属性を使用すると、ハブから 500 が応答されます。これは、呼び出しが承認されたビューから来ている場合と、匿名のビューから来ている場合の両方です。

リクエスト (sendメッセージを送信するための Hub メソッド):

http://localhost:8101/signalr/send?transport=serverSentEvents&connectionToken=VIXEZzWQSn5SNlA8RUy4iaOPDFdvuPBjMvFBiG2FLfvfxF347XHwtapsEV5ndU4OEI0Xb64W2ZRXTqwBiL2CXg2_JlTaTJ2RnVOj4bjvx6tQaYhAqTaXs9k2853GYqzd0

応答：

The connection id is in the incorrect format.

Server stack trace:
   at Microsoft.AspNet.SignalR.PersistentConnection.GetConnectionId(HostContext context, String connectionToken)
   at Microsoft.AspNet.SignalR.PersistentConnection.ProcessRequest(HostContext context)
   at Microsoft.AspNet.SignalR.Owin.CallHandler.Invoke(IDictionary2 environment)
   at Microsoft.AspNet.SignalR.Owin.Handlers.HubDispatcherHandler.Invoke(IDictionary2 environment)
   at Microsoft.Owin.Host.SystemWeb.OwinCallContext.Execute()
   at Microsoft.Owin.Host.SystemWeb.OwinHttpHandler.BeginProcessRequest(HttpContextBase httpContext, AsyncCallback callback, Object extraData)<br/><br/>

ただし、Hub への接続は正常に機能し、200 OK が返されることに注意してください。
http://localhost:8101/signalr/connect?transport=serverSentEvents&connectionToken=dYOwFxa1mkgdpzw-jitRpWq9oxRlrTet8U_dAzWjFQEdGNJfVXeG7Op0NZZwvznxeNdJCuPT75CKzQqI9HRPThV3uEDt-Z2qtIl9E02gF481&connectionData=%5B%7B%22name%22%3A%22chathub%22%7D%5D&tid=9

ここで、stackoverflow で類似のスレッドをほとんど見つけませんでした:
signalr 接続 ID が正しくない形式です


私のメソッドを呼び出すとき、ハブはハブへの接続に使用されたものとは異なるSendリクエストを処理していること、またはハブの発見、そのユーザーは実際には承認されていないことを理解していますが、承認がない場合にその仮定をどのようにチェックするかハブ自体で指定されていますか? IdentityGetConnectionId

誰かがこれに光を当てることができますか？

前もって感謝します ：）

4

2 に答える 2

9

SignalR は、新しい接続を開始するたびに新しい接続Identityを作成するために、接続 ID と一緒に両方に署名します。connectionTokenこれconnectionTokenは、negotiate応答の一部として SignalR クライアントに送信されます。

connect、reconnect、またはsend要求のいずれであっても、SignalR に要求を行うたびに、SignalR はconnectionToken、クライアントの接続 ID と の両方に一致することを確認しますIdentity。

これconnectionTokenは基本的に、サード パーティの Web サイトを実行している攻撃者が、共有クライアントに代わって SignalR 要求を密かに作成するのを防ぐために使用される CSRF トークンです。SignalR のクロスドメイン サポートを有効にしている場合、明らかにこれは役に立ちませんがconnectionToken、この場合でも同じように機能します。

テイラーの答えは正しかった。クライアントが変更されたら、SignalR 接続を行う必要がstopあります。これにより、クライアントの更新された新しい署名付きの新しい接続 ID をクライアントに与える新しい要求が強制されます。startIdentitynegotiateconnectionTokenIdentity

PS サーバーから送信されたイベントconnectリクエストは、クライアントが変更される前に確立されたため、失敗しませんIdentity。はconnectionTokenリクエストが受信されたときにのみチェックされますが、サーバー送信イベントはレスポンスを無期限に開いたままにします。

于 2013-03-19T18:40:44.967 に答える
3

それはあなたが言ったことすべて真実であり、それは実際に私の問題で起こります.

しかし、根本的な原因もわかりました。
設計中の主な前提の 1 つは、匿名ユーザーがサインインせずにチャットを使用できるようにすることと、バックエンド ユーザー (エージェント) がチャットの制限された領域にサインインできるようにすることでした。 Windows 資格情報。

そのため、IIS マネージャーでは、匿名認証 (匿名ユーザーがチャットを使用できるようにする) と Windows 認証 (エージェントが Windows 資格情報を使用してアクセスできるようにする) の両方を有効にしました。
MVC アプリケーションは、Windows 認証を使用するように構成されてい[Authorize]ます。これは、問題で言及されている属性ですが、エージェントのチャット ビューへのアクセスを制限するためだけです。

上記の構成で実際に起こることは次のとおりです。
1. クライアント (エージェント) が制限されたビューを要求すると (たとえば/Chat/Agent)、[Authorize]属性が認証を初期化します (Windows)
2. クライアント側の Javascript 要求Negotiate、それを生成connectionIdしてクライアントの Windows にバインドするものIdentity
3. ここにトリッキーな部分があります: ハブは使用しないため任意の認証を明示的に行うと、メソッドを呼び出しsendても認証リクエストは発生しません - IIS 匿名認証は Windows 認証よりも優先され、sendリクエストは匿名で送信されますIdentity- しかし、ハブでは実際にポイント 2 で渡されることにconnectionId関連しています。 このシナリオは、あなたが説明した状況につながります -と Hub の戻り値とは異なる方法で呼び出されますIdentity

connectIdentitysendThe connection id is in the incorrect format.

于 2013-03-20T20:41:04.643 に答える