Service Fabric 反向代理与 SignalR 协商答案

【问题标题】：Service Fabric Reverse Proxy with SignalR negotiateService Fabric 反向代理与 SignalR 协商
【发布时间】：2020-05-01 17:18:54
【问题描述】：

我正在为我的有状态服务连接到 SignalR 集线器的反向代理 url，当 SignalR 尝试建立连接时，javascript 客户端调用协商端点，该端点返回一个 url 参数，然后尝试将其用于连接端点。问题是返回的 url 参数是集群上暴露的端点侦听器的部分路由。 http://localhost:19081/MyServiceFabiricApplication/MyStateFulService/signalr/negotiate?clientProtocol=2.1&PartitionKey=1&PartitionKind=Int64Range

成功返回

{"Url":"/9fd06df9-4399-4ea8-8771-9875b6ee4026/132235137104318266/8d308cc3-2fd7-40a6-96c3-2e521bf384ef/signalr",...

如何告诉 signalR 忽略从协商返回的 URL 并使用我最初提供的反向代理 URL 进行连接？最终的问题是它将返回的路由与我最初提供的反向代理 url 混合在一起，因此连接尝试使用带有反向代理端口但结构节点的路由的 fankenstein url。这导致 404。

ws://localhost:19081/9fd06df9-4399-4ea8-8771-9875b6ee4026/132235137104318266/8d308cc3-2fd7-40a6-96c3-2e521bf384ef/signalr/connect

这是因为从协商端点返回的路由必须通过我的端点的暴露端口直接调用，即 5102。

   ws://localhost:5102/9fd06df9-4399-4ea8-8771-9875b6ee4026/132235137104318266/8d308cc3-2fd7-40a6-96c3-2e521bf384ef/signalr/connect

不知何故，我需要在它尝试连接之前修复 url，因为它从协商生成的那个是错误的。

【问题讨论】：

标签： signalr reverse-proxy azure-service-fabric service-fabric-stateful

【解决方案1】：

我最终使用了一个 ajax 数据过滤器来拦截协商响应并将 url 重写回反向代理

   jQuery.ajaxSetup({
  dataFilter: (data, type) => {
    //modify the data
    if (~data.indexOf('ConnectionToken') && ~data.indexOf('Url') & ~data.indexOf('TryWebSockets')) {
      var dataobj = JSON.parse(data);
      dataobj.Url = this.ServiceProxyUrl + "signalr";
      return JSON.stringify(dataobj);
    }
    return data;
  }
});

【讨论】：