0
  • TFS 2013
  • Windows Server 2012
  • IIS 8.5
  • Application Request Routing (ARR)

I'm using ARR for a reverse proxy to reroute any requests for a URL on that server to the IP address that I have setup for TFS on that server.

Everything works great, except in Chrome (don't get to say that very often).

When browsing the web version of my TFS install and visiting a "Team Room", I get a SignalR error in the Chrome console:

403 (Forbidden: SignalR cross domain is disabled.)

The same link in FF and IE works fine. Also, if I visit the Team Room link directly via the TFS IP address (bypassing ARR), it works fine.

I've tried a bunch of different things to solve the issue.

Adding this header to the web.config for TFS

<add name="Access-Control-Allow-Origin" value="http://tfs.mydomain.com"/>

Setting the connection URL of the SignalR connection in JavaScript and using JSONP like so:

$.connection.hub.url = "http://my.ip.address:8080/tfs/signalr"; 
options = ({jsonp: true})
$.connection.hub.start(options)

I even tried another approach I found online which disabled the cache on ARR.

Many solutions out there say that I should enable cross domain requests for SignalR on the server, however since this is for a TFS install, I don't have the freedom to modify the binaries for TFS (as far as I know) and I wasn't able to find a way to do this on the client by looking at the SignalR API.

The only other answer I came across for this problem was that Chrome is bugged and not to use it (which is undesirable).

Does anybody know how I can use Chrome to access TFS team room functionality?

Always Learning
  • 2,623
  • 3
  • 20
  • 39
  • If there is a bug in Chrome then I would look to Google for a fix. – MrHinsh - Martin Hinshelwood Jan 05 '15 at 09:26
  • That exactly my question, is this a bug and if so has anyone found a workaround? – Always Learning Jan 05 '15 at 19:05
  • Have you seen this: http://stackoverflow.com/questions/15367968/cross-domain-will-not-work-with-a-signalr-persistentconnection ? – Pawel Jan 05 '15 at 22:04
  • Pawel, yes I have but thank you for sharing. The main issue here is that the fix recommended assumes you have access to the server side code and since this issue is with the binaries associated with a TFS install, I don't have access to that server side code to make those changes (as far as I know). – Always Learning Jan 06 '15 at 00:52

1 Answers1

2

I don't know the answer, but I have the same problem and some information.

I used Fiddler to examine the HTTP request to see what was different between the requests sent from Chrome and from IE. Chrome sends an "origin" header along with the "referrer"; IE doesn't. I used Fiddler's Filter option to dynamically remove the "origin" header and Chrome works normally as long as Fiddler is capturing.

These are some of the headers sent from Chrome:

Origin: https://[domain]
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: https://[domain]/tfs/_rooms

Removing the "Origin" header in Fiddler's filters allows Chrome to work.

Robert Taylor
  • 2,860
  • 3
  • 21
  • 19
  • 1
    That's interesting. I tried the above with Fiddler and it did work as you said. Unfortunately I can't find a way to remove a request header. I tried this in the TFS web.config but it didn't work (I'm sure it isn't meant to be used this way but I am grasping at straws at the moment): – Always Learning Jan 06 '15 at 08:01