Posts made by nuno.guerreiro.rosa_9280

@atripp The main goal for me is to be able to fetch the latest tag for a particular docker image so I can display in a custom badge.
For NuGets I have the API shown below:

Get Latest Version number of a package:
https://«proget-server»/nuget/{feed-name}/Packages()?$filter=Id%20eq%20%27«package-name»%27%20and%20IsAbsoluteLatestVersion&$top=1

For docker images I would like to query based on the tag list to get the last one created but I can't seem to find a good option to do with this API if there is no ordering capabilities. It should be a simple requirement to query a docker image and get the last created tag.

I also confirm I didn't get any more timeouts on the latest version. Very good!

Hi,

There is an API method called /tag/list which returns this unordered tag list.
Are you able to add a query string parameter ?order=date to produce a result ordered at least by tag created date? I don't think it should be that challenging to do and I do see the benefits of getting the TAGs ordered according to the Date they were created..

In my honest opinion, it should by default order by created date. I shouldn't even need to provide the query string. That way it would be even easier to implement.

@atripp This is probably related with the same issue i kept mentioning which you were saying it was possibly due to an overloaded network stack or other type of configurations. I still have the problem even after setting up a completely new server so it also shows that any timeout is related with proget application code. Looking forward to try out this fix. This apparently was happening to other users as well. :)

Is there any way querying proget native API or any other available API where I can get the latest tag pushed for a particular docker image ?

The closest I got was using the endpoint below but ideally there would be an endpoint that returns literally the latest version (tag) of a docker image.

https://proget-repository.mydomain.com/v2/feed-docker/docker-image-name/tags/list

I have also tried to get the last item from the tags list array and that would be the default "latest" tag. Querying -1 from the last index would return the correct last version until your version goes "1.0.100", then -1 from last won't be returning latest version anymore.

Is there an alternative ?

Thanks

@atripp I did not mean 1GB of packages from ProGet. It was just an example, I get them from public NuGet without a problem since they can handle the load. On docker build there is no package cache, only docker layer cache, that means everytime a csproj is modified a full .net restore will be performed and I might get around 100+ packages downloaded. From 100+ packages around 5 are in fact in ProGet. 100 requests ( I think NuGet performs 16 concurrent requests at a time) is in fact very low to cause any network stack overload. All I was asking was to test 100+ packages being restored (NuGet.Config with a public NuGet feed and a ProGet authenticated feed) and only 5-10 of those packages should be in ProGet. 90+ requests will return no package found or something similar. Maybe not found requests are the ones that might cause the problem ?
If you have tested similar examples and have no issues then I might have some problem with my configuration. I will setup a new server this time with NGINX. Is it possible to use PostgreSQL with ProGet instead of SQL server or not supported anymore ? Thank you for your help.

@atripp Its only a single connector with one feed. Try to do a single restore which pulls 1GB of NuGet packages but from ProGet it pulls only 5mb however NuGet will still hit ProGet for all those requests and 90 % of responses will be to reply that the package was not found. When I have some free time I will create a complete different setup on another Linux server to verify if its something with the traefik proxy. I would like that you attempt this type of restore in your test server and clear all nuget cache and tell me your results. Restore time in sec / try to load Proget UI during the restore, etc.

@rhessinger said in Even after .NET Core upgrade a single client doing a .NET restore causes timeouts too easily:

Hi @nuno-guerreiro-rosa_9280,
Do you have any other applications connecting to your SQL enterprise instance? Do you see any timeouts in those applications? Would you be able to run a docker stats when these timeouts are occuring? Could you also up your timeout in ProGet's SQL Server connection string?
Also, what version of SQL server are you running?
Thanks,
Rich

I do not have any other applications connected to the SQL instance. Only Proget.
Using "mcr.microsoft.com/mssql/server:2019-latest" version.

As you can see below there is no load at all on the server.

If I look at SQL Server connections there is almost no load in regards to the number of connections.
Increasing the connection timeout made no actual difference. I have also profiled the SQL Server and all queries are relatively fast so there are no slow performance queries either.

This clearly only happens when it's a full dotnet restore due to several parallel requests. If I throttle to 1 request there are no issues in Proget, however, it doesn't make sense that with a single user on a single dotnet restore this timeouts start occurring and the UI becomes also unresponsive.

Thank you. this situation seems to be sorted in 5.3.15.

If for some reason the client has no packages locally (ie: Within a docker build where there are no local packages) it will query proget in order to obtain them. Rarely I am able to do a full dotnet restore without seeing a timeout error in Proget. The error seems to be coming from timeouts querying the DB, so even with enterprise version and load balancing this problem would probably be worse.

The server where it is hosted is more than enough to handle the load of a single client. SSD, 4 cores, and 32 GB RAM and with enterprise SQL Server too which has very few connections open when these errors occur.

I see many errors like the one below: (this package doesn't exist in proget, however since it is in NuGet.Config will still query ProGet.

Retrying 'FindPackagesByIdAsyncCore' for source 'https://proget.xxx.io/nuget/xxx-nuget/FindPackagesById()?id='System.Diagnostics.Process'&semVerLevel=2.0.0'.
Response status code does not indicate success: 504 (Gateway Timeout).

In proget web I see many errors like:

An error occurred processing a GET request to http://proget.xxx.io/nuget/xxx-nuget/v3/flatcontainer/system.text.json/index.json: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

stack trace:
System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
---> System.ComponentModel.Win32Exception (258): Unknown error 258
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action1 wrapCloseInAction) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose) at System.Data.SqlClient.SqlCommand.EndExecuteNonQueryInternal(IAsyncResult asyncResult) at System.Data.SqlClient.SqlCommand.EndExecuteNonQuery(IAsyncResult asyncResult) at System.Threading.Tasks.TaskFactory1.FromAsyncCoreLogic(IAsyncResult iar, Func2 endFunction, Action1 endAction, Task`1 promise, Boolean requiresSynchronization)
--- End of stack trace from previous location where exception was thrown ---
at Inedo.Data.SqlServerDatabaseContext.CreateConnectionAsync()
at Inedo.Data.DatabaseContext.ExecuteInternalAsync(String storedProcName, GenericDbParameter[] parameters)
at Inedo.Data.SqlServerDatabaseContext.ExecuteInternalAsync(String storedProcName, GenericDbParameter[] parameters)
at Inedo.Data.DatabaseContext.ExecuteTableAsync[TRow](String storedProcName, GenericDbParameter[] parameters)
at Inedo.ProGet.Feeds.NuGet.V2.LocalPackageSource.FindPackagesByIdAsync(NuGetQueryOptions options, String id) in C:\InedoAgent\BuildMasterTemp\192.168.44.60\Temp_E75101\Src\ProGetCoreEx\Feeds\NuGet\V2\LocalPackageSource.cs:line 161
at Inedo.ProGet.Feeds.NuGet.NuGetFeed.FindPackagesByIdAsync(NuGetQueryOptions options, String id) in C:\InedoAgent\BuildMasterTemp\192.168.44.60\Temp_E75101\Src\ProGetCoreEx\Feeds\NuGet\NuGetFeed.cs:line 157
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.V3.PackageBaseAddressHandler.ProcessRequestAsync(NuGetFeed feed, HttpContext context, String relativeUrl) in C:\InedoAgent\BuildMasterTemp\192.168.44.60\Temp_E75101\Src\ProGet.WebApplication\FeedEndpoints\NuGet\V3\PackageBaseAddressHandler.cs:line 39
at Inedo.ProGet.WebApplication.FeedEndpoints.FeedEndpointHandler.FeedRequestHandler.ProcessRequestAsync(HttpContext context) in C:\InedoAgent\BuildMasterTemp\192.168.44.60\Temp_E75101\Src\ProGet.WebApplication\FeedEndpoints\FeedEndpointHandler.cs:line 192
ClientConnectionId:631e8659-835c-43aa-8815-79f9c5633cf5
Error Number:-2,State:0,Class:11

Some other errors in the container logs:
An error occurred processing a GET request to http://proget.xxx.io/nuget/xxx-nuget/v3/flatcontainer/system.memory/index.json: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

An error occurred processing a GET request to http://proget.xxx.io/nuget/xxx-nuget/v3/flatcontainer/microsoft.extensions.primitives/index.json: ExecuteNonQuery requires an open and available Connection. The connection's current state: Broken.

Can you please investigate what can we do about it? I would rather it takes longer to restore than all these timeout errors.

Note that this is with proget core. Also maybe there are more efficient ways to identify if a package does exist or not before querying the DB. Cache options?

PS: While this situation is occurring, the proget web becomes unresponsive and it stays loading forever until the requests are completed.

Thank you

@rhessinger Hi, Is it possible to release this fix before 30th October or not really ? I am unable to upgrade until then. I guess anyone who uses docker registry authentication in this case.

@rhessinger I have done some more testing and confirm that the NuGet restore is now working however the docker login (Unauthorized error) is still failing so that still remains to be fixed. Maybe the same issue but now with docker login ?

Login did not succeed, error: Error response from daemon: login attempt to https://proget.myinstance.io/v2/ failed with status: 401 Unauthorized

/var/log/syslog

Oct 10 23:54:21 docker01 dockerd[1079]: time="2020-10-10T23:54:21.726102349+02:00" level=info msg="Error logging in to v2 endpoint, trying next endpoint: login attempt to https://proget.myinstance.io/v2/ failed with status: 401 Unauthorized"
Oct 10 23:54:21 docker01 dockerd[1079]: time="2020-10-10T23:54:21.727052689+02:00" level=error msg="Handler for POST /v1.37/auth returned error: login attempt to https://proget.myinstance.io/v2/ failed with status: 401 Unauthorized"

@rhessinger I have upgraded to ProGet v5.3.13 and the login issue still occurs. I had to revert back to progetmono to be able to perform docker login.

@rhessinger Nice to hear, looking forward to try a final version so I can upgrade to .net core version and with some luck, will achieve better performance because I am running it in 4 vCPU server with 32 gb ram and its not very normal that with a single client when doing a net restore it starts throwing timeout exceptions. Have you tried to do some load tests on restore to find out why it overwhelms the server so easily? Let's say I have 40 nuget packages from public nuget.org and 2 from proget. It will still query 40 packages in proget to find out it doesn't exist in the server. I believe those 40 package checks might be overwhelming the server. Just a guess.

@rhessinger Thank you very much.

@rhessinger I have upgraded to proget:5.3.13-ci.5 and both NuGet restores and docker login started failing

Error
administrator@docker01:/opt/proget$ docker login proget.myinstance.com
Username: example
Password: example
Error response from daemon: login attempt to https://proget.myinstance.com/v2/ failed with status: 401 Unauthorized

/var/log/syslog
Oct 7 08:36:55 docker01 dockerd[1079]: time="2020-10-07T08:36:55.735970715+02:00" level=info msg="Error logging in to v2 endpoint, trying next endpoint: login attempt to https://proget.myinstance.com/v2/ failed with status: 401 Unauthorized"
Oct 7 08:36:55 docker01 dockerd[1079]: time="2020-10-07T08:36:55.736102221+02:00" level=error msg="Handler for POST /v1.37/auth returned error: login attempt to https:/proget.myinstance.com/v2/ failed with status: 401 Unauthorized"

administrator@docker01:/opt/proget$ docker version
Client:
Version: 18.03.1-ce
API version: 1.37
Go version: go1.9.5
Git commit: 9ee9f40
Built: Thu Apr 26 07:17:20 2018
OS/Arch: linux/amd64
Experimental: false
Orchestrator: swarm

Server:
Engine:
Version: 18.03.1-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.5
Git commit: 9ee9f40
Built: Thu Apr 26 07:15:30 2018
OS/Arch: linux/amd64

OS information:
NAME="Ubuntu"
VERSION="16.04.6 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.6 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

Dotnet restore on windows fails on all packages:

C:\Program Files\dotnet\sdk\3.1.401\NuGet.targets(128,5): error : Failed to download package 'xxxx.1.0.5' from 'https://proget.myinstance.com/nuget/feed-nuget/v3/flatcontainer/xxxx/1.0.5/xxx.1.0.5.nupkg'.
C:\Program Files\dotnet\sdk\3.1.401\NuGet.targets(128,5): error : Response status code does not indicate success: 401 (Unauthorized).

@rhessinger I will try to upgrade again when I have some time with the latest ci which has the case sensitive fix and let you know the behavior. The mono version is working fine though.

In proget core I have noticed that by default there is log level info enabled which spams in the console per request which might overwhelm the system when there are too many concurrent requests. How can I change the log level to error ? Thank you.

@rhessinger Built in directory.

@rhessinger The user actually has view and download. I don't think its related with that since mono works fine. I don't know if me going to the file system and rename all directories/ nupkg to lower case without changing anything in the database could have caused any issue. Is there any data related to package name stored in the DB? That was the only manual operation I did after the upgrade cause of that bug that apparently was found and fixed on the latest version. (proget:5.3.13-ci.2)

Lets say in file system I had My.Package.Hello/My.Package.Hello.nupkg and I renamed to my.package.hello/my.package.hello.nupkg

@atripp Hi, have you tried to set anonymous user with view package only and setup a user with download package permissions and try to restore a package with a private authenticated feed using dotnet restore (NuGet.Config with credentials in clear text)? I don't have anything special in the setup. The error on dotnet restore is the typical unauthorised error as when you type a wrong password. My setup is traefik docker container -> proget core docker container in ubuntu Linux host.

It's relevant to mention as well that in all versions, including mono I still get the below error when doing NuGet package restores. Usually, it occurs with full restores without any package cached but I guess it shouldn't happen anyway. This is only with a single client doing a restore.

An error occurred processing a GET request to http://myproget.blabla.com/nuget/feed-nuget/v3/flatcontainer/microsoft.extensions.dependencyinjection/index.json: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.

URL: http://...../nuget/feed-nuget/v3/flatcontainer/system.runtime.interopservices/index.json
Referrer: (not set)
User: (unknown)
User Agent: NuGet .NET Core MSBuild Task/5.7.0 (Microsoft Windows 10.0.19041)
Stack trace: at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection (System.Data.Common.DbConnection owningConnection, System.Threading.Tasks.TaskCompletionSource1[TResult] retry, System.Data.Common.DbConnectionOptions userOptions, System.Data.ProviderBase.DbConnectionInternal oldConnection, System.Data.ProviderBase.DbConnectionInternal& connection) [0x0024d] in <0864334e7e474248b37afca9b637daa9>:0 at System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal (System.Data.Common.DbConnection outerConnection, System.Data.ProviderBase.DbConnectionFactory connectionFactory, System.Threading.Tasks.TaskCompletionSource1[TResult] retry, System.Data.Common.DbConnectionOptions userOptions) [0x00036] in <0864334e7e474248b37afca9b637daa9>:0
at System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection (System.Data.Common.DbConnection outerConnection, System.Data.ProviderBase.DbConnectionFactory connectionFactory, System.Threading.Tasks.TaskCompletionSource1[TResult] retry, System.Data.Common.DbConnectionOptions userOptions) [0x00000] in <0864334e7e474248b37afca9b637daa9>:0 at System.Data.SqlClient.SqlConnection.TryOpen (System.Threading.Tasks.TaskCompletionSource1[TResult] retry) [0x0005d] in <0864334e7e474248b37afca9b637daa9>:0
at System.Data.SqlClient.SqlConnection.Open () [0x0003b] in <0864334e7e474248b37afca9b637daa9>:0
at Inedo.Data.SqlServerDatabaseContext.CreateConnection () [0x0006c] in <13a07e71a6964ed9849f50a505055a64>:0
at Inedo.Data.DatabaseContext.ExecuteInternal (System.String storedProcName, Inedo.Data.GenericDbParameter[] parameters) [0x00064] in <13a07e71a6964ed9849f50a505055a64>:0
at Inedo.Data.SqlServerDatabaseContext.ExecuteInternal (System.String storedProcName, Inedo.Data.GenericDbParameter[] parameters) [0x00005] in <13a07e71a6964ed9849f50a505055a64>:0
at Inedo.Data.DatabaseContext+<>c__DisplayClass29_01[TRow].<EnumerateTable>b__0 () [0x00000] in <13a07e71a6964ed9849f50a505055a64>:0 at Inedo.Data.StrongDataReader+<Read>d__111[TRow].MoveNext () [0x0003e] in <13a07e71a6964ed9849f50a505055a64>:0
at System.Linq.Enumerable.TryGetFirst[TSource] (System.Collections.Generic.IEnumerable1[T] source, System.Boolean& found) [0x00045] in <22384ee444974b39bb55b725de39c721>:0 at System.Linq.Enumerable.FirstOrDefault[TSource] (System.Collections.Generic.IEnumerable1[T] source) [0x00000] in <22384ee444974b39bb55b725de39c721>:0
at Inedo.ProGet.Data.DB+Context.Feeds_GetFeed (System.Nullable`1[T] Feed_Id, System.String Feed_Name) [0x0003d] in <9e25495e1bef4b848a026d26a04c0c9c>:0
at Inedo.ProGet.Feeds.Feed.GetFeed (System.String feedName, Inedo.ProGet.Data.DB+Context externalDbContext) [0x0000b] in <9e25495e1bef4b848a026d26a04c0c9c>:0
at Inedo.ProGet.WebApplication.FeedEndpoints.FeedEndpointHandler.GetHttpHandler (Inedo.Web.Handlers.GetHandlerParams args) [0x0017e] in <a8aace96ff954f2f8794684dd8c734d6>:0
at Inedo.Web.Handlers.DynamicHttpHandling.GetHandler (System.Web.HttpContext context, System.String requestType, System.String url, System.String pathTranslated) [0x0003b] in <13a07e71a6964ed9849f50a505055a64>:0
at Inedo.Web.InedoHttpModule.MapHandlerAndBeginRequestAsync (System.Web.HttpApplication app) [0x00029] in <13a07e71a6964ed9849f50a505055a64>:0
at Inedo.Web.InedoHttpModule.HandleBeginRequestInternalAsync (System.Web.HttpApplication app) [0x0000f] in <13a07e71a6964ed9849f50a505055a64>:0
at Inedo.Web.InedoHttpModule.ProcessBegin (System.Object sender, System.EventArgs e, System.AsyncCallback cb, System.Object extraData) [0x0000d] in <13a07e71a6964ed9849f50a505055a64>:0
at System.Web.HttpApplication+<RunHooks>d__217.MoveNext () [0x000a4] in <b4f0b153c02f4f0588d3f7549d75281b>:0
at System.Web.HttpApplication+<Pipeline>d__225.MoveNext () [0x0012c] in <b4f0b153c02f4f0588d3f7549d75281b>:0
at System.Web.HttpApplication.Tick () [0x00000] in <b4f0b153c02f4f0588d3f7549d75281b>:0

@atripp Hello atripp. Just to be clear, this occurs not only authenticating with docker but also with private NuGet authenticated feeds. I have just switched to progetmono and both private docker and NuGet feeds are authenticating correctly so the issue is related to the .NET Core release.

The setup is Traefik -> Proget -> SQL Server.
WebBaseUrl is set as it was in the previous version so should not be related either.

After upgrading docker 5.3.11 to 5.3.12 and fixing the case sensitive packages by renaming all packages/directories to lower case, everything seems to be working fine beside authentication. Both NuGet private feed authentication and docker login stopped working, however I can login from the proget UI.

Found the issue... Apparently, after the upgrade, any package needs to be in lower case, otherwise, it won't be found. That is actually a breaking change.

When upgrading from proget.inedo.com/productimages/inedo/proget:5.3.11 to proget.inedo.com/productimages/inedo/proget:5.3.12 or progetcore:5.3.11 and even the mono version, it doesn't find the NuGet packages on disk anymore and it throws the exception below, even though they are in the disk storage and the path specified in the feed is correct. Any idea what is the issue?

System.IO.FileNotFoundException: Unable to find the specified file.
at Inedo.ProGet.Extensions.FileSystems.CaseInsensitiveFileSystem.OpenFileAsync (System.String fileName, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Boolean requireRandomAccess) [0x0014f] in <9e25495e1bef4b848a026d26a04c0c9c>:0
at Inedo.ProGet.Feeds.NuGet.NuGetFeed.OpenLocalPackageAsync (System.String id, Inedo.ProGet.Feeds.NuGet.NuGetVersion version) [0x001bb] in <9e25495e1bef4b848a026d26a04c0c9c>:0
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetApi+GetHandler.TransmitPackageAsync (System.Web.HttpContext context, Inedo.ProGet.Feeds.NuGet.INuGetPackage package, System.String packageFileName, System.Boolean includeSymbols, System.Boolean includeSource, System.Boolean includeSignature, Inedo.ProGet.Feeds.NuGet.NuGetFeed feed) [0x00070] in <a8aace96ff954f2f8794684dd8c734d6>:0
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetApi+GetHandler.ProcessGetRequestAsync (System.Web.HttpContext context, Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetApi+RequestData urlData, Inedo.ProGet.Feeds.NuGet.NuGetFeed feed) [0x00625] in <a8aace96ff954f2f8794684dd8c734d6>:0
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetApi.ProcessRequestAsync (System.Web.HttpContext context, Inedo.ProGet.Feeds.NuGet.NuGetFeed feed, System.String relativeUrl) [0x00111] in <a8aace96ff954f2f8794684dd8c734d6>:0
at Inedo.ProGet.WebApplication.FeedEndpoints.FeedEndpointHandler+FeedRequestHandler.ProcessRequestAsync (System.Web.HttpContext context) [0x0018a] in <a8aace96ff954f2f8794684dd8c734d6>:0

@atripp I will try the progetcore when I manage to have some time but I can confirm the issue I reported was solved in proget v5.3.10. Thank you.

@rhessinger The issue was solved with v5.3.10 release. Thank you.

Thank you for the support. Looking forward for the fix.

Any feedback in regards to this issue? It looks related to the new localization feature added on v5.3.9

If I open any page like https://www.myinstance.com I get the exception.
If I open any other page like https://www.myinstance.com/feeds it works so it must be a problem with this v.5.3.9 version.

The exception above occurs in the home page but I saw other pages which also throws a similar exception like browsing package versions.
I have rolled back to v5.3.8.

Thank you and will be waiting for the release since its quite a security problem.

After I attempt an upgrade from the docker Linux container from v5.3.8 to v5.3.9 I am getting the following exception when loading the web UI.
In the docker container logs both for the SQL Server and Proget instance, everything seems to be working fine.

Any idea what might be the issue?

I have just bumped the version and did a docker-compose up.

Message: An error occurred in the web application: Object reference not set to an instance of an object
Stack trace: at Inedo.ProGet.WebApplication.RuntimeLocalizationDictionary.GetCurrent () [0x00006] in <2602fa8c19cc4155be9186cda413e6a1>:0
at Inedo.ProGet.WebApplication.RuntimeLocalizationDictionary.get_Current () [0x00000] in <2602fa8c19cc4155be9186cda413e6a1>:0
at Inedo.ProGet.WebApplication.LocalizationHelpers.GetValue (System.String key) [0x00000] in <2602fa8c19cc4155be9186cda413e6a1>:0
at Inedo.ProGet.WebApplication.Localization+RootPage+FeedsTable.get_Feeds () [0x00000] in <2602fa8c19cc4155be9186cda413e6a1>:0
at Inedo.ProGet.WebApplication.Pages.RootPage.CreateBottomPanels (Inedo.ProGet.Data.DB+Context db) [0x00243] in <2602fa8c19cc4155be9186cda413e6a1>:0
at Inedo.ProGet.WebApplication.Pages.RootPage.CreateChildControlsAsync () [0x00138] in <2602fa8c19cc4155be9186cda413e6a1>:0
at Inedo.ProGet.WebApplication.Pages.ProGetSimplePageBase.InitializeAsync () [0x0006c] in <2602fa8c19cc4155be9186cda413e6a1>:0
at Inedo.Web.PageFree.SimplePageBase.ExecutePageLifeCycleAsync () [0x0007c] in <8a0468ee94a94ef1b2bba97871f29990>:0
at Inedo.Web.PageFree.SimplePageBase.ProcessRequestAsync (System.Web.HttpContext context) [0x00080] in <8a0468ee94a94ef1b2bba97871f29990>:0
at System.Web.TaskAsyncResult.Wait (System.IAsyncResult result) [0x00032] in <b4f0b153c02f4f0588d3f7549d75281b>:0
at System.Web.HttpTaskAsyncHandler.System.Web.IHttpAsyncHandler.EndProcessRequest (System.IAsyncResult result) [0x00000] in <b4f0b153c02f4f0588d3f7549d75281b>:0
at Inedo.Web.Handlers.AsyncHandlerWrapper.EndProcessRequest (System.IAsyncResult result) [0x00000] in <8a0468ee94a94ef1b2bba97871f29990>:0
at System.Web.HttpApplication.async_handler_complete_cb (System.IAsyncResult ar) [0x00015] in <b4f0b153c02f4f0588d3f7549d75281b>:0

In the proget free version, in v5.8.3 (docker image), when an anonymous user has only ViewFeed permission, he can somehow still create feeds when he is not logged in. That does not make sense. Any idea why this behaviour ?

Any way I can allow the anonymous user to view feeds but not being able to create it.

If I go into proget.inedo.com I notice the correct behaviour. I am anonymous and if i try to create a feed it will redirect me to the login page.