Team Foundation Server (Beta 2) over HTTP

 I can’t wait anymore!!!!  I’ve lied and I admit it… and I feel so ashamed. Ok, perhaps that’s a little too dramatic and I’m not even certain that I’ve lied.  But I may have misled people…

One of the things I do for a living is provide Team System training.  And during that training we talk about distributed teams.  We have slides and labs that we’ve developed along with Microsoft, et. al., which discuss the fact that Team Foundation Server is HTTP-based to enable distributed development.  All of the slides that truly talk to remote teams are centered on the Team Foundation Version Control (TFVC) portion of the product, but there were implications that the system was fully HTTP-based.  If you were in one of my classes and understood that to be the case, I apologize.

How do I know it’s not true? There seems to be a glitch in B2 that caused the challenge/response authentication mechanism in VS2005 Beta 2 to only work the first time you connect to the server.  Last week I pursued a work-around for this ‘feature’ for one of our clients; I chose to build an HTTP proxy with the authentication information built-in.  I was able to connect to a remote TFS Server, list and select projects, and operate with the version control system fairly easily through the authentication proxy.  But when I drilled into the Team Project in Team Explorer, I would get one or more application or security related errors.  I didn’t get the reporting or document library portions of the Team Explorer to work, but I suspect that if I’d been more persistent with security configurations I might have been successful.  I was able to list builds remotely but couldn’t really interact with them.  But my real issue: I couldn’t get Work Items to work!!!!

When I pulled out a network sniffer I was shocked to discover some un-identified TCP traffic that went over the network when I was trying to access the work item subsystem!  The traffic looked the similar regardless of whether I was trying to access work items from Team Explorer or Excel.  Needless to say, my ‘simple’ HTTP proxy was out of the question.

I was hoping to see a release of the July CTP with (wishful thinking) the authentication bug gone and/or everything running over HTTP.  When the CTP comes out, I will review it and let you know if it looks any better.

I guess if there is a bright side, the install at the client site went well and we were able to work around the authentication – we at least have a happy customer and a successful VSTS installation.

Published Monday, July 25, 2005 5:02 PM by dmckinstry

Comments

# re: Team Foundation Server (Beta 2) over HTTP

Monday, July 25, 2005 6:21 PM by J Rosenberg

Dave,

You said you deployed TFS for a client. I was curious because I have heard there is not a upgrade path for the full version. This has held us off since we do not want to create work when the RTM version comes out. Have you come up with a workaround or is the client satisfied with possible headache down the road?

Just curious.

-J

# re: Team Foundation Server (Beta 2) over HTTP

Monday, July 25, 2005 6:46 PM by Dave McKinstry

Hi J,

You are right about the lack of a guaranteed migration route. We've provided basic instructions on how to manually migrate only the most recent version of source control and work items, knowing that they would loose history and have to do some manual cleanup. They are satisfied with the answer although it wouldn't be ideal for all users.

-Dave

# re: Team Foundation Server (Beta 2) over HTTP

Monday, July 25, 2005 7:37 PM by Ron Buckton

One apparent workaround is to remove the autoload="true" from the teamexplorer.config before starting vs.net and you will be required to reauthenticate.

# re: Team Foundation Server (Beta 2) over HTTP

Monday, July 25, 2005 9:25 PM by Drew Marsh

Maybe I'm just missing something, but isn't that to be expected? It relies on Windows authentication and therefore uses Kerberos to figure out who you are. Of course that wouldn't go through HTTP, so I don't think you can classify this one as a bug. You should be able to try the same thing by turning Windows authentication on for an IIS directory and trying to hit it with IE.

Cheers,
Drew

# re: Team Foundation Server (Beta 2) over HTTP

Tuesday, July 26, 2005 1:49 AM by Dave McKinstry

Ron - thanks for the feedback. I wasn't aware of the autoload in teamexplorer.config.

Drew - Perhaps you're right. After setting the web services virtual root to support basic authentication and inserting credential information into the HTTP header, I was able to connect to the TFS, select a team project, and access the version control with the correct credentials. I assumed that the principal would be managed appropriately through IIS, but this area is certainly not my specialty. In any case, I'm hearing more buzz that all will be well by RTM. Thanks.

# re: Team Foundation Server (Beta 2) over HTTP

Tuesday, July 26, 2005 1:10 PM by Drew Marsh

If you do use basic authentication you're seriously compromising your Windows network security if any of the traffic isn't over HTTPS, so I'd be careful with that. :) Even with a secure VPN users inside of the network could clearly get at other people's windows credentials so even that's not a great option.

As far as it "all being well by RTM" I'm really not sure what they can do about it. It's not really a problem with Team System, it's just the way Windows auth works. Guess I'll keep an eye on your blog to see what you find come RTM. ;)

-Drew

# re: Team Foundation Server (Beta 2) over HTTP

Tuesday, July 26, 2005 1:19 PM by Dave McKinstry

Thanks for the insightful dialog. I was considering two ways of handling the clear text issues of basic authentication, one of which would be HTTPS.

To clarify the RTM comment, when they fix the authentication challenge/response bug in beta 2, I won't need the proxy. (See J Rosenburg's comment above for an alternative work around.)

I look forward to 'chatting' with you again!

Leave a Comment

(required) 
(required) 
(optional)
(required)