Open parnham opened 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.
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.
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";
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
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.
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.
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
We are testing out the standalone server and have it behind a basic auth nginx proxy configured as follows:
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.