Open alpaix opened 7 years ago
There's a second, possibly related, issue that has been bothering us for a long time. Visual Studio 2015 and now also Visual Studio 2017 tend to prompt for credentials in a dialog window often. I think this happens when you have not saved the credentials using your default browser for the domain of the feeds. (The feeds have a web interface with a login page.)
Visual Studio and nuget.exe should not rely on the browser cache when packageCredentials are configured in NuGetDefaults.config, they should be read from NuGetDefaults.config for each request/query instead.
@ygeelen-tb This does sound like a different issue. Please file a new one so we could investigate and address it separately.
The 2nd issue that @ygeelen-tb is articulating sounds similar to https://github.com/NuGet/Home/issues/4615
@alpaix Can you please assign someone to fix this?
I created a separate issue for the second issue #4953 but it isn't getting much attention it seems.
Credential caching is still done based on the host. See: https://github.com/NuGet/NuGet.Client/blob/cbb5064e22ae0782d2fd8900e44bf0cd0409999e/src/NuGet.Clients/NuGet.Credentials/CredentialService.cs#L223
To fix this the client would need to understand the structure of the url so that other services on the same host re-use the cached credentials, but other feeds do not. For v3 index.json could point to any location, higher or lower than the original index which makes this difficult.
Potentially the client could ignore the cache and retry if the url was not an exact match. This would lead to more prompting for credentials, but it would enable it to get the right credentials.
As reported by @ygeelen-tb. The customer set up a multi-tenant host hosting feeds requiring different permissions and/or set of credentials:
The expectation is that NuGet.exe would send correct set of credentials to each feed URI. Instead it always sends the same credentials of the first accessed feed. The problem is NuGet caches credentials using host segment of feed URI only.
The bug #2151 was fixed in 3.5/3.6 internal release with NuGet/NuGet.Client#607. As confirmed by the customer this regressed again in 4.0.0-rtm-2283.