Javascript 长轮询的信号器连接错误详细信息

Javascript 长轮询的信号器连接错误详细信息,javascript,asp.net,signalr,long-polling,Javascript,Asp.net,Signalr,Long Polling,在jquery.signalR-1.1.3.js中,longpolling error函数传回响应文本,而不是整个jqXHR对象 有没有一种好方法可以在集线器错误处理程序中确定错误实际上是什么 $.connection.hub.error(function (error) { system.log('SignalR error: ' + error); }); 我使用了signar[Authorize]属性在应该拒绝连接时返回一个HTTP403禁止的,但

在jquery.signalR-1.1.3.js中,longpolling error函数传回响应文本,而不是整个jqXHR对象

有没有一种好方法可以在集线器错误处理程序中确定错误实际上是什么

$.connection.hub.error(function (error) {
            system.log('SignalR error: ' + error);
        });
我使用了signar
[Authorize]
属性在应该拒绝连接时返回一个
HTTP403禁止的
,但在我的客户端中,我得到的只是错误对象中的IIS错误页面响应页面,因为signar没有传回整个响应对象,请参见下面的:
$(实例)。triggerHandler(events.onError,[data.responseText];
。这是在一个紧密的循环中发生的,因为信号器只是不断尝试重新连接几百次/千次/任何时间,直到重新连接超时过去

我想知道它是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;
}
出现了几个问题

  • 为什么信号机会像那样在一个紧密的环路中重新连接
  • 是否有更好的方法基于集线器连接的授权来控制信号器连接生命周期
  • 这是一个在2.0中修复的bug,它将在1.1.5中修复
  • 是的,如果用户未经授权,请确保不呈现尝试进行信号器连接的页面

  • #1-很好,我能理解。#2-这并不能回答关于使用signalR authorize属性来授权连接的问题,它只是提供了一种不同的方法…我的应用程序目前不使用这种方法。两种方法都可以,对吗?您可以将authorize属性保留在集线器上,但您可以确保没有人访问该页面,除非他们是用户lso已授权,这样signalr客户端就不会对未经授权的用户发狂。如果这不是一个选项,那么唯一的其他方法就是自己更改signalr javascript。这一点很好,我实际上同时做了这两件事。我目前正在处理的问题是,使用相同的auth cookie,测试人员在浏览器中克隆选项卡(可能所有这些都应该具有相同的有效Asp.NET Auth cookie)处于使signalR Authority属性返回403的状态。谢谢David。