JetBrains / teamcity-nuget-support

TeamCity NuGet support
Apache License 2.0
43 stars 11 forks source link

Standalone server not using https in package feed #6

Open parnham opened 10 years ago

parnham commented 10 years ago

We are testing out the standalone server and have it behind a basic auth nginx proxy configured as follows:

   proxy_set_header X-Real-IP $remote_addr;
   proxy_set_header Host $http_host;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header X-Forwarded-Proto https;
   proxy_pass http://127.0.0.1:8888;

The package feed contains the correct server name and path throughout the XML but all of the URLs are http and not https which means the packages will not download via the nuget plugin.

NickCraver commented 10 years ago

We're having the same issue at Stack Overflow, it seems to stem from logic similar to this (example here):

WebUtil.getRootUrl(request)

While the TeamCity server itself is getting an HTTP request, that's from behind a load balancer. This messes up all the feed links and auth since http:// is incorrect and will get redirected to https://. This also means the auth header isn't re-sent, so it results in a login loop inside Visual Studio.

The nuget plugin should instead use the root server URL specified in the General Settings section to generate its URLs.

parnham commented 10 years ago

Well the X-Forwarded-Proto header is the standard* way of indicating protocol when dealing with load balancing proxies, so perhaps the getRootUrl function is not checking for that particular header.

\ Not official standard, but what everyone seems to use.

NickCraver commented 10 years ago

That would appear to be the case, we're passing both X-Forwarded-Proto and X-SSL with no joy here. Relevant nginx configs from our side:

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-SSL "yes";
jonnyzzz commented 10 years ago

You need to have an connector in your Tomcat instance with secure=true specified. So this would make Tomcat generate https URLs for requests.

See http://youtrack.jetbrains.com/issue/TW-20584#comment=27-305463 for more details

NickCraver commented 10 years ago

This isn't a viable solution, it assumes the servers gets only https requests. When you are behind a load balancer that handles SSL termination the Tomcat server gets an http request with the proper proxy headers we've indicated above. We access our TeamCity server over both http and https depending on if the request is internal or external (hairpin routing necessitates this).

The nuget feed should return URLs matching what was requested or at the very least match the server URL specified in general settings, currently it does neither and results in an infinite login loop for SSL load balancer users.

parnham commented 10 years ago

In addition, this bug is regarding the standalone server "standalone-nuget-feed.jar", as far as I'm aware there is no instance of Tomcat running and no configuration to modify.

jonnyzzz commented 10 years ago

Sorry, I thought the problem was related to TeamCity's NuGet Feed. For the standalone NuGet Feed server you may need to patch the way Jetty is started. The main trick is you may make Jetty think protocol is secured (htts) without having SSL configured for connection. So this would make it generate right URL.

Another trick could be to simply add an option for explicit URL to be created

You may consider to provide patch for this to standalone3 branch