Support private feeds
Opened this issue · 58 comments
Support authentication for private feeds. Also, consider package management using a login system.
See https://docs.microsoft.com/en-us/nuget/reference/extensibility/nuget-exe-credential-providers
HTTP basic auth: https://gist.github.com/DutchCaveman/4287549fc36dace5ac780ce023ddb05a
Client certificate auth: NuGet/Home#5773 (comment)
Symbol server PAT auth: dotnet/diagnostics#1321 (comment)
/cc @emgarten
Not sure about managing packages, but if the feed were private it would be great to have a simple system for managing the basic auth creds.
Ah yup, that'd be great too. I'll update the issue!
MyGet has their own credential provider that supports different identity providers: http://docs.myget.org/docs/reference/credential-provider-for-visual-studio
NuGet cross platform authentication providers: NuGet/Home#6486
Rider has done some work on this too: https://blog.jetbrains.com/dotnet/2018/03/06/credential-providers-private-nuget-feeds-rider-2018-1-eap/
@loic-sharma: It'd be great to have a simple user / groups management too. Only teams and members. A package can be owned by a team or a membmer and a member could join teams. Like the NuGetGallery feature.
Identification could be done via different api keys.
TODO - Read about AAD device flow: https://joonasw.net/view/device-code-flow
TODO - Read about OpenId https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server
VSTS's implementation: https://github.com/Microsoft/artifacts-credprovider
Simple basic auth like nuget server
@DoCode Yes, I'd like to add that in as well. I'll flesh out this issue soon with all the things I'd like to implement.
Hi, any update on this issue? Even a basic auth mechanism would be of great help! Thx
Sadly, I haven't made any progress on this in a while. I just came back from vacation, I'd like to catch up on everyone's contributions/questions before tackling on this problem again.
i think the biggest challenge here is the creation of a development and test environment...
Some investigations to get a better understanding of the challenge......
(please correct me if i am wrong)
this link points to the current authentication
logic implemented inside the NuGet Client.
basically the following 2 lines are doing the work:
clientHandler.Credentials = _credentials;
clientHandler.UseDefaultCredentials = false;
credentials can be
- username/password (in case of basic auth)
- token (access token, bearerer token etc) in case of a token based auth methods.
There is NOTHING about typical OAuth/OpenIDConnect workflows etc.... because this steps (go to the auth server, redirects etc) must be implemented inside the CredentialsProvider.....
=> nice, KISS (keep it small and simple)
For BaGet we have two different challenges
a) UI must implement the full auth workflow for the configured auth system (basic auth, oauth, openidconnect)
b) a headless version of BaGet must only ensure that all (relevant) Controllers are requireing authentication/authorization with the configured token implementation
PLUS: there must be a CredentialsProvider in place that implements the auth workflow....
which (core) CredentialsProvidersd are available now ?
Not many i think....
Idea for a first playground:
- assume headless usage (ignore UI)
- configure basic auth
- find a way to inject this credentials into NuGet Client, worst case write (simple) a CredentialsProvider
if basic auth is working we have the foundation to implement OAUTH/OpenIDConnect/Azure-AD etc.....
may be after Basic auth we can implement a Github based auth (i prefer develope against stable/well known system - deveolping agains a self hosted identity server brings to many variables into dev)
later we can test/develop agains a self hosted Identity Server and other implementations.....
just a few ideas about how to....
Started my own investigations.... but i need some help or new ideas
-
added a few authentication/authorization settings to BaGet for "Basic Authenttication"
basic auth seems working if 'm calling the Index Controller with a HttpClient and a typical request header for Basic Auth. -
created a small .net 4.6 Project with current nuget.exe inside
nuget.config pointing to my BaGet Instance (localhost, running in VS)
when i'm calling "nuget list -s XXX" or "nuget restore -s XXX"
2.1. i see the incoming Request (AuthenticationHandler) in BaGet
2.2 returning "Unauthenticated" for this request, nuget.exe asks me for username+password
2.3 i see the next request from nuget.exe BUT there is NO Auth-Header inside this request.
any idea why ?
basically the request header in 2.2 and 2.2 is the same like the following:
Connection=Keep-Alive
Accept-Encoding=gzip, deflate
Accept-Language=en-US
Host=localhost:50561
User-Agent=NuGet Command Line/4.9.3 (Microsoft Windows NT 6.2.9200.0)
X-NuGet-Session-Id=453811c6-e5be-4b21-9fff-ea5dbee5f845
X-NuGet-Client-Version=4.9.3
@loic-sharma any idea ?
where i'm wrong inside the Nuget client auth workflow ?
Edit: all my assumtions are based on the code inside NuGet.Protocol.HttpSourceAuthenticationHandler
Hey @WernerMairl, I haven't had the chance to look to deeply into how the client does authentication yet. I'll try my best to answer your questions, but I'm not a domain expert here. The client's authentication stack is owned by @nkolev92, so I'll forward any question I can't answer to him.
i see the next request from nuget.exe BUT there is NO Auth-Header inside this request.
@loic-sharma any idea ?
where i'm wrong inside the Nuget client auth workflow ?
I'm not very familiar with the client code base, so I don't know. I would recommend building the NuGet client and poking around with a debugger. I'll ask @nkolev92 in person at work on Monday.
- find a way to inject this credentials into NuGet Client
You can inject credentials by creating an authentication plugin (see this documentation). I thought that the client could fallback to basic auth, but I may be wrong. You may need to create a plugin even for this scenario.
which (core) CredentialsProvidersd are available now ?
The only open source provider that I'm aware of is Azure Artifact's provider, which uses OAuth: https://github.com/Microsoft/artifacts-credprovider
Thanks for making progress here! By the way, how can I IM you? Do you have Skype? It'd be easier to communicate that way :)
skype user: ironrookie
i know that at the end of the day we may need a CredentialProvider but this is also a complex feature that i try to avoid for the moment (to many variables in place)
another source for a (raw) CredentialProvider i have found there:
https://github.com/NuGet/NuGet.Client/tree/dev/test/TestExtensions/TestablePluginCredentialProvider
@WernerMairl
The 2nd linked plugin is not the V2 plugin architecture and it will go away in the next release.
I'm not sure why there's no auth header when you provide user and creds on the commandline.
Can you try specifying them in a config file and see if that makes any difference?
Nothing found :-( but now i'm ready to publish my playground, that may help!
my workspace: a BaGet clone with a branch "feature/auth":
https://github.com/mssforks/BaGet/tree/feature/auth
it contains
- a protototype for Basic Authentication
- launch settings for Kestrel with a hard coded Port-Number on Localhost
- [Authorize] Attributes for most of the Controllers
- a Authentication Handler that should do the Authentication, located here:
https://github.com/mssforks/BaGet/blob/feature/auth/src/BaGet/Extensions/BasicAuthenticationHandler.cs
starting at line 57 where i use System.Diagnostics.Writleline to print out the entire request header
It doesn't matter how i call nuget.exe - i get always the same header trace (Missing AUTH Header)
Connection=Keep-Alive
Accept-Encoding=gzip, deflate
Accept-Language=en-US
Host=localhost:50561
User-Agent=NuGet Command Line/4.9.3 (Microsoft Windows NT 6.2.9200.0)
X-NuGet-Session-Id=3479ee6c-3c22-435a-804c-a9992fdfc7d9
X-NuGet-Client-Version=4.9.3
Cookies.Count=0
this is how i configure/call nuget:
(see at the cmd)
https://github.com/mssforks/nugetcaller
@nkolev92 can you give a look at my infos ?
what i can say:
- nuget.exe seems to see and select the right config file
- it uses the correct host and port
- in interactive mode it shows the username provided inside config file
- using cleartext or not doesn't help
- using interactive doesn't help
how to reproduce:
- download, compile and run https://github.com/mssforks/BaGet/tree/feature/auth
- execute cmd in https://github.com/mssforks/nugetcaller
thank you in advance
Werner
@nkolev92 and @loic-sharma ignore my last posts - problem solved.....
(result 401 is not enough, you must return things like "WWW-Authenticate" on the response header....)
THEN you get auth headers.... from httpclienthandler....
Now fighting with token based security, but i think it is solved - when i get a confirmation about my findings there:
May be we are not enforced to write our own Credentialprovider, we can re-use one from another (Microsoft) Product (VSTS etc.... if the license allows this)
Prototyping for Token based Authentication (JwtBearer) Feedback required!
After creating 3-5 prototypes and working drafts, the last idea looks as the best
(specially in terms of KISS)
MAIN Challenge:
The NuGet Client (nuget.exe and dotnet restore) does not follow (or implement) the RFC for AuthenticationScheme "Bearer" => The Authentication Infrastructure provided by AspNetCore can't be used.
One of my older prototypes solves this by re-implementing the entire AuthHandler (only the small part of Token-Validation can be re-used from ASPNetCore).
The Prototype is working and the way may be a good sample how to solve problems like this.
But it feels not KISS (keep it simple, stupid) - rewriting half of the AspNetCore Middleware is not a good idea.....
last prototype (the best until now): https://github.com/mssforks/BaGet/tree/feature/jwtfeed
It implements a middleware that rewrites Request and Response in a way, that they are "translated" between nuget.exe (non-rfc) and RFC for Bearer Token
-
the sample is working locally ignoring the ui (i'm working only with nuget.exe as client at this moment => headless)
-
use this jwt-token "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1bmlxdWVfbmFtZSI6Im15dXNlcmlkIiwibmJmIjoxNTUxNTEyNzAzLCJleHAiOjE1NTIxMTc1MDIsImlhdCI6MTU1MTUxMjcwM30.zOwfSJT-fvEFT-3exm3PDapvKtkVVLMtzV2xNO42HqQ "
or generate new one with this gist -
the signature key (secret) currently is hardcoded and not part of the appsettings
you can use nuget.exe with the followung custom source:
nuget sources add -Name bgbearer -source "http://localhost:50561/v3/index.json" -username dummyUsername -password "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1bmlxdWVfbmFtZSI6Im15dXNlcmlkIiwibmJmIjoxNTUxNTEyNzAzLCJleHAiOjE1NTIxMTc1MDIsImlhdCI6MTU1MTUxMjcwM30.zOwfSJT-fvEFT-3exm3PDapvKtkVVLMtzV2xNO42HqQ" -StorePasswordInClearText -ConfigFile %configfile%
Other token based auth methods (OAuth, AAD etc) should be easy to implement now....
Next Steps (helpful)
- feedback/discussion/ decision if this is the way that we go
- if we agree in some way we should create (preview) builds from master or a "development" branch, i expect a lot of discussions and details to solve but a compiled version with feedback from some early adopters may be helpful!
Thanks for all the progress @WernerMairl! Your solution of using a token with basic auth is pretty interesting, but it seems like regenerating the token periodically would be a little painful. What do you have in mind for this? Could we instead use the API key used to push packages as the basic auth password?
I still think that token authentication is the "proper" way to authenticate clients, but that's harder to get right.
Summary of my findings/learnings/investigations
-
I have implemented "Basic" Security (with credentials). It is working and may be helpful in some special scenario BUT not considered for the future.
The implementation was helpful to test customizings, interfaces and test code -
my implementation for AAD is following the same idea and samples like yours in PR#69 - a few problems with configuration settings (not well implemented in the original samples from MS) are solved
-
tecnically "token-based" is the right way, including Azure Active Directory (AAD), OpenIdConnect, OAuth etc....
regenerating the token periodically would be a little painful
Agree - but we have to deal with "modern security requirements and workflows".
That means: i have not found any way on AAD to get long living (access) tokens
You can customize AAD to increase the default life time (~2 hours) by a few 100% - but this is not considered (security) and a complex AAD-Customizing and it doesn't solve the problem because the increased lifetime is "not enough".
AAD is following the concept of "short living access tokens, long living refresh tokens" (https://www.oauth.com/oauth2-servers/differences-between-oauth-1-2/short-lived-tokens-long-lived-authorizations/)
that means the (access) token MUST be generated periodically (we are talking about lifetime in 1-2 hours).
Important: the input for the regeneration is NOT a credential dialog (UI) but a (long living) refresh token created on the first call to the STS.
this regeneration can be done silently (without UI) in the background BUT this is the typical job that must be implemented inside the CredentialProvider !!
That means we NEED a token based CredentialProvider in every case.
Current automated build systems like BitBucket Pipeline, Travis etc. are injecting "long living" tokens via Environment variables.
How we can do that with AAD ?
On a Build Server scenarios we can inject a (long living) refresh token into the build system and then NuGet Client+CredentialProvider can do requests to our private feed for "years"....
(remember refresh tokens are long living, they allow us to get short living access tokens for long long time, but with the costs of a call to the STS every few hours)
Other findings that may be helpful/ideas/shortcuts
The default Credential Provider for VisualStudio/VSTS etc. provided by Miccrosoft at https://github.com/Microsoft/artifacts-credprovider
contains 98% of all that we need.
The required changes and remaining work is minimal, basically they do everything that we need for a token based worklfow (because vsts is implemented in exactly THIS way)
the only problem: the AAD Instance that is used is hardcoded (Cloud-VSTS Main Instance) and can't be changed without recompiling the package
(here the source code: https://github.com/Microsoft/artifacts-credprovider/blob/master/CredentialProvider.Microsoft/CredentialProviders/Vsts/VstsAdalTokenProviderFactory.cs)
Worst case: the entire "artifacts-credprovider" repo is under MIT License... we can clone.
But maybe someone has the rights contacts to suggest a improvement in our direction (customizing) ... we can provide PR.
- you can customize (hack) the TokenValidation process inside BaGet to ignore the Token Lifetime => not considered, helpful in development scenarios
- you can use our own STS instead of AAD and create long living tokens....
During my prototyping i have created a CredentialProvider that works with AAD
- using the first access token (not implemented refresh token)
- using the Device Workflow
NEXT STEPS
- Improve UI to allow OpenID Connect workflows (with Azure AAD and any other STS)
- implement a CredentialProvider for token absed security (includes AAD)
my personal plan:
- starting multiple instances of BaGet (docker based, using Azure Web App for Linux) with different AUTH scenarios => playground for test,dev and verifications)
- BASIC AUTH (1 hard coded (dev) credential that can be provided here)
- TOKEN based AUTH with long living tokens created with a console app provided here (console app==STS)
- AAD sample (i have a AAD for dev up and running)
- adopting UI for private feeds
- CredentialProvider
Any help is welcome => we should skype about my plan..
btw: currently i'm using docker cloud build to create docker images from my fork....
Source code Update:
My current/newest draft is here: https://github.com/mssforks/BaGet/tree/feature/AADSquash
It is based on BaGet/master from today (March 16) and contains only one commit with all the changes (all the commits between are valueless because to often try/error)
if we agree to merge in some way into the main Repo, we can define a strategy for smaller commits/pull requests (feature by feature or assembly by assembly)... that i can provide.
last improvements:
- Controllertests improved for Authentication (using Classfixtures)
- tests for Basic Authentication
- tests for JwtBearer authentication (using a Token creator inside the TestFixture)
@WernerMairl — first thanks for your contribution!
Summary of my findings/learnings/investigations
- I have implemented "Basic" Security (with credentials). It is working and may be helpful in some special scenario BUT not considered for the future.
The implementation was helpful to test customizings, interfaces and test code
Why not for the future? Why 'only' helpful in 'some special' use cases?
Many in our company and partners around the world and myself think the default basic authentication is THE most and simplified authentication method for all use cases in self-hosted, on-premise NuGet servers for what this project should stand. Some of us doesn't understand so much effort.
Unfortionaly some of us think the time would better be invested in a multi-tenant architecture like MyGet (currently the monopolist in this area).
So, please do not get wrong, but this is our opinion, and we would only that this project is developing in the right direction. :-)
Hi
@DoCode
a) personal opinion yes, but open for other suggestions (and i'm only a contributor - i'm not driving the project....)
b) i like the expected discussion ;-)
I agree with the requirement of "simplified authentication" and i know that AAD is NOT simple....
I'm assuming (opinion) that Basic Auth is "too simple" and someone may overlook the impact and sideeffects:
Basic Auth is simple during the Auth process but has a lot of effort and risks in his backend.
We must implement a user database with credentials (Passwords!!!!).
Doing Password handling/persistence in the right way is a never ending nightmare (data breaches, GDPR)
Thats what i mean with "only' helpful in 'some special' use cases"
But i think my concerns can be solved with architecture (SoC Separation of Concerns)
a) we can/should continue to split BaGet into a set of (NuGet) Packages that can be recombined for different usage scenarios.
Then we/someone can implement all the required things for basic auth without impacting the core.
b) my personal suggestion for "simplified authentication" is (long living) token based - but instead of AAD we can start our own (preconfigured) STS using architecture from a)
At this moment i'm working on a few BaGet Instances (demos) hosted as Azure WebApps with different Authentication scenarios.
I think a good playground to isolate and define "simplified authentication"
Werner
First playground opened:
https://bagetbasic.azurewebsites.net
with the following configuration
- basic authentication ON (Username "dummyUser", Password "dummyPassword")
- ApiKey empty - everyone can push but i had some problem with nuget.exe to investigate.
- NewtonSoft.Json pushed there (currently the one and only package until someone else pushes others)
- Mirroring (NuGet.org) Enabled but not tested/verified
Surprising:
I have NOT touched the Baget WebUI but it works.
It seems that the current Web UI/Framework has a default Basic Authentication workflow enabled so you get a Credentials Dialog from the UI and after putting there "dummyUser" and "dummyPassword" you can see the current content (Newtonsoft)
Your demo looks great @WernerMairl! Could you open up a pull request for basic auth? :)
I'd say we should start with basic authentication as it'll have the easiest setup experience. I agree there's some serious concerns with basic auth, but those can be addressed with the more advanced AAD/STS flows.
That means we NEED a token based CredentialProvider in every case.
I think this is acceptable for AAD/STS flows.
Worst case: the entire "artifacts-credprovider" repo is under MIT License... we can clone.
I think this is the approach I'd like to take in the short term.
But maybe someone has the rights contacts to suggest a improvement in our direction (customizing) ... we can provide PR.
I can find contacts if needed (I'm on the NuGet team at Microsoft). I think it'd be interesting to add an extension to the NuGet protocol that allows for token based authentication. If so, we could bake this experience right into NuGet. Let's see how this goes on BaGet first though!
question about the size of the pull request
my current code base contains
80 % infrastructure code required for all types of AUTH
10 % code for Basic Auth
10 % code for Token/AAD
a) i can create a FULL PR
b) i can create a smaller (90% PR) in the next days.....
how we proceed ?
regards Werner
Hi
@DoCode
a) personal opinion yes, but open for other suggestions (and i'm only a contributor - i'm not driving the project....)
b) i like the expected discussion ;-)I agree with the requirement of "simplified authentication" and i know that AAD is NOT simple....
I'm assuming (opinion) that Basic Auth is "too simple" and someone may overlook the impact and sideeffects:Basic Auth is simple during the Auth process but has a lot of effort and risks in his backend.
We must implement a user database with credentials (Passwords!!!!).
Doing Password handling/persistence in the right way is a never ending nightmare (data breaches, GDPR)
Thats what i mean with "only' helpful in 'some special' use cases"But i think my concerns can be solved with architecture (SoC Separation of Concerns)
a) we can/should continue to split BaGet into a set of (NuGet) Packages that can be recombined for different usage scenarios.
Then we/someone can implement all the required things for basic auth without impacting the core.
b) my personal suggestion for "simplified authentication" is (long living) token based - but instead of AAD we can start our own (preconfigured) STS using architecture from a)At this moment i'm working on a few BaGet Instances (demos) hosted as Azure WebApps with different Authentication scenarios.
I think a good playground to isolate and define "simplified authentication"Werner
Hi @WernerMairl ,
thanks for your reply!
Sorry, sorry... I am going to back one step!
What we mean with simply Basic Auth is ONLY relevant on client tools, such nuget.exe or Visual Studio Package Manager or NuGet Client libs.
We and all of our partners, devs and automated servers and frameworks only access and consume NuGet packages through client tools and here all we and customers need is Basic Auth!
On the web front, it's completely different for UI's like NuGet Gallery and the one in BaGet. In an early post, I mentioned that the BaGet UI should be separated because in 80% we think it's not necessary!
Last night I put in basic auth from a nuget package (I cannot remember which one), but have just seen your demo.
This looked like fine apart from the Index packages being visible and you can cancel the User/Password prompt to enter the site?
Do you have any packages on the demo?
newtonsoft.json now should be there
- uploaded 2 weeks ago but lost in the meantime because no long time storage configured
- re-pushed a few minutes ago
i have re-pushed newtonsoft using the following cmd:
(the instance is configured with a empty API-Key, so feel free to push some samples)
@@echo off
set nupkg=%~dp0Newtonsoft.Json.12.0.1.nupkg
set configfile=%~dp0nugetbgbasic.config
nuget locals http-cache -clear
echo delete existing config file and re-create from empty.config
IF EXIST %configfile% DEL /F %configfile%
copy %~dp0empty.config %configfile%
echo add sample source 'bgbasic' with Password in clear text
nuget sources add -Name bgbasic -source "https://bagetbasic.azurewebsites.net/v3/index.json" -username dummyUser -password dummyPassword -StorePasswordInClearText -ConfigFile %configfile%
nuget push %nupkg% -source "https://bagetbasic.azurewebsites.net/v3/index.json"
current issue with this script/nuget.exe call
it is working BUT you must (re)type credentials into console during nuget push
(i have to figure out some detail)
Cool, nice job. Now it's clear until you're logged in you don't see any packages.
I wasn't sure where any of this was up to, so I just deployed a simple nginx reverse proxy container that adds basic auth with one set of credentials. If anyone is interested, it's here: https://github.com/shaneqld/nginx-basic-auth-rproxy
The auth functionality would really be fantastic. We implemented a IP whitelist on the ingress for our Kubernetes pod, but it's not sustainable (e.g. cannot work remotely).
Exactly. I was also using a whitelist but that stopped being a solution when we started building using a cloud build provider with indeterminate ip addresses. So now it’s: a load balancer that adds tls <> the nginx reverse proxy that adds auth <> baget. Will keep like this until there’s suitable auth in baget.
That's funny, I came up with the same solution as @shaneqld and I wanted to share my experience.
It works like a charm!
In Visual Studio just add the source:
After opening your project's package manager select the previously added package source.
Next, you will be prompted to type in your credentials:
Any update for private feed release ?
Would love to see this feature in BaGet.
Until then i also use reverse proxy, nginx with basic auth using Docker since it's pretty easy to configure.
I just can't see myself using Baget since there is no authentication anywhere in it.
any updates on this ticket?
Hi, I'm working on adding an account system to BaGet to allow private feeds. Progress has been slow due to lack of time, but it's coming!
@loic-sharma How can we help?
Ju downloaded BaGet to try. So right now without no auth system for private feeds, does that mean my private packages can be pulled by anyone using hostedurl.com/baget and list of packages can be seen? What right now is the best way to protect thue UI from public access?
@Alik2015 that is correct. Since there is no authentication, the listing is public, unless you configure your server differently. If you want to use BaGet with some kind of authentication at the moment, you could configure an reversed proxy. And then in the webserver configure basic authentication. Which is also posted above, as an suggested workaround for the moment.
My current plans:
- Support NuGet's legacy V2 APIs
- Upgrade to .NET 6
- Add private feeds
Until then, please use a reverse proxy to add certificate or basic HTTP authentication to your BaGet app.
- Add private feeds
Add private feeds ! greert. I need it
Any update on this feature ? :)
I have made a fast-forward implementation (sorry, a lot of work currently, and I needed a fast solution) for a private like NuGet server. It's not any kind of user, team privacy, but I think it takes privacy to the NuGet server itself. I needed a nuget-source for a project with private code and available for private pipelines. My idea was to put the apikey into the route (so don't use it without https). I hope the Idea does anyone help : https://github.com/scaliebe/BaGet
@scaliebe Thanks for sharing! If you haven't already, make sure to add rate limits to your server to protect against brute force attacks.
Any new update for
Support NuGet's legacy V2 APIs
Upgrade to .NET 6
Add private feeds
@loic-sharma
thanks in advance
Any update for private feed release ?
I have made a fast-forward implementation (sorry, a lot of work currently, and I needed a fast solution) for a private like NuGet server. It's not any kind of user, team privacy, but I think it takes privacy to the NuGet server itself. I needed a nuget-source for a project with private code and available for private pipelines. My idea was to put the apikey into the route (so don't use it without https). I hope the Idea does anyone help : https://github.com/scaliebe/BaGet
Hello ，I realy need this,Can you provide a use case for https://xx.com/{apikey}? nginx reports error 502
I have made a fast-forward implementation (sorry, a lot of work currently, and I needed a fast solution) for a private like NuGet server. It's not any kind of user, team privacy, but I think it takes privacy to the NuGet server itself. I needed a nuget-source for a project with private code and available for private pipelines. My idea was to put the apikey into the route (so don't use it without https). I hope the Idea does anyone help : https://github.com/scaliebe/BaGet
Hello ，I realy need this,Can you provide a use case for https://xx.com/{apikey}? nginx reports error 502
If you're using my fork, you need to set the apikey in appsettings.json. Then you can go to the URL of the BaGet server by browser. Now login with your apikey. Select the connect tab at the top and copy your service index URL. It's something like "https://xx.com/apikey/v3/index.json"
I have not tested it with nginx yet, I host it at IIS at the moment!
Rather use gitea which has private feeds and built-in package managers for many platforms, including .NET. And it will never become abandonware as so many people use it.
是使用具有私有源和内置包管理器的平台，适用于许多平台，包括 .NET。而且它永远不会成为废弃软件，因为有这么多人使用它。
gitea
thank,I was changed after apikey packaging directly to your project to the docker, then on the server using nginx mount HTTPS access, https://xx.com/apikey/v3/index.json in this form is true, but is unable to access, The same original version of baget can be accessed. But thanks for telling me that you only run it on IIS, I'll try the same, thanks again
I finally decided to use NGINX for encryption, which felt simpler
In this way, only the IP address of the company can be guaranteed when uploading, and the IP address of the Nuget.config file can be unlimited when downloading
thank again
# 允许访问者只要满足 allow 或 auth_basic 的其中之一即可 satisfy any; # 允许的 IP 范围 allow 192.12.1.1; deny all; # 账号密码保护 auth_basic "Restricted Content"; auth_basic_user_file /etc/nginx/.htpasswd_xxxx;