1

jquery.signalR-1.1.3.js では、longpolling エラー関数が jqXHR オブジェクト全体ではなく、応答テキストを返します。

ハブ エラー ハンドラで実際のエラーを特定する良い方法はありますか?

$.connection.hub.error(function (error) {
            system.log('SignalR error: ' + error);
        });

SignalR[Authorize]属性を使用してHTTP 403 Forbidden、接続を拒否する必要がある場合に を返しましたが、SignalR は応答オブジェクト全体を返さないため、クライアントではエラー オブジェクトの IIS エラー ページの応答ページしか取得できません。以下を参照してください$(instance).triggerHandler(events.onError, [data.responseText]);。これは、再接続タイムアウトが経過するまで、SignalR が数百回、数千回、または何回でも再接続を試行し続けるため、タイトなループで発生します。

それが 403 であること、または私が返す可能性のあるカスタム ステータス コードであることを伝え、それに応じてアプリが応答できるようにしたいと考えています。この場合は、再接続の試みをやめてログアウトします。

longpolling トランスポートのエラー ハンドラは次のとおりです。

error: function (data, textStatus) {
// Stop trying to trigger reconnect, connection is in an error state
// If we're not in the reconnect state this will noop
window.clearTimeout(reconnectTimeoutId);
reconnectTimeoutId = null;

if (textStatus === "abort") {
    connection.log("Aborted xhr requst.");
    return;
}

// Increment our reconnect errors, we assume all errors to be reconnect errors
// In the case that it's our first error this will cause Reconnect to be fired
// after 1 second due to reconnectErrors being = 1.
reconnectErrors++;

if (connection.state !== signalR.connectionState.reconnecting) {
    connection.log("An error occurred using longPolling. Status = " + textStatus + ". " + data.responseText);
    $(instance).triggerHandler(events.onError, [data.responseText]);
}

// Transition into the reconnecting state
transportLogic.ensureReconnectingState(instance);

// If we've errored out we need to verify that the server is still there, so re-start initialization process
// This will ping the server until it successfully gets a response.
that.init(instance, function () {
    // Call poll with the raiseReconnect flag as true
    poll(instance, true);
});

}

およびサーバー側のハブ認証コード

public override bool AuthorizeHubConnection(Microsoft.AspNet.SignalR.Hubs.HubDescriptor hubDescriptor, Microsoft.AspNet.SignalR.IRequest request)
{
    // If we want them to connect, return true, else false
    // Asp.NET will return a 403 if we return false here
    return false;
}

いくつかの疑問が生じます...

  1. signalR がそのようなタイトなループで再接続するのはなぜですか?
  2. ハブ接続の承認に基づいて signalR 接続のライフサイクルを制御するより良い方法はありますか?
4

1 に答える 1

0
  1. これは 2.0 で修正されたバグであり、1.1.5 で修正される予定です。
  2. はい、ユーザーが承認されていない場合に SignalR 接続を確立しようとするページをレンダリングしないようにしてください。
于 2013-09-19T16:47:02.330 に答える