Hi @apxltd

Your description sounds perfect. Look forward to seeing this in a future version.

Also your software products rock! Keep up the great work!

Thanks

Simon

Hi @atripp

I like your "tags that use this layer" suggestion, I was also thinking you could do something like this mock-up within the repo view:

In addition you could also improve the "feed view" with some more information about the number of tags/images & vulnerablities per repo like this:

Or even:

Hey Guys,

Hoping to submit a feature request here.

In Proget you should provide the ability for a user to manage their own API keys via the web interface.

At the minute API keys need to be setup by an administrator and assigned to a user via the impersonate user field.

It would be nice if the user was able to create their own API key via the user menu here:

Use case:

Access to proget is setup using AD authentication and assigning an AD group (not ad user) with the correct privilege's.

The user then needs an API key to use with CI/CD tools on the users workstation.

Today:

Administrator needs to login to admin portal, add the ad user with the correct "security", then generate an API key and "impersonate" the user that has just been setup.

Required state:

User logs into the web portal and generates their own key that inherits the users current permission set.

Thanks

Simon

Its the Windows VM instance of ProGet that is the issue. Yes i've restarted both the ProGet Service and the IIS app pool.

When installing the InedoCore extension from the Web UI I don't get an option which version it installs. I presume 1.13.4 as that is the 'latest' version as shown in the screenshot above

My extension page looks like this:

I've tried deleting the extensions from the Web UI (and I see the .upack file deleted on the file system) and re-adding it from the web UI however I still get this error.

Thanks

Simon

Hi Support,

I'm attempting to migrate our ProGet instance from Docker to a dedicated Windows 2019 Virtual Machine.

I've installed ProGet 6.0.13 (same as docker version) from InedoHub and backup/restored the database and updated the advanced settings with all the correct directories.

All is functioning correctly on the new VM apart from the extensions, I'm getting the following error when ProGet is trying to load them:

System.Runtime.Serialization.InvalidDataContractException: Type 'Inedo.Extensibility.UpackMetadata' cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute. If the type is a collection, consider marking it with the CollectionDataContractAttribute. See the Microsoft .NET Framework documentation for other supported types. at System.Runtime.Serialization.DataContract.DataContractCriticalHelper.ThrowInvalidDataContractException(String message, Type type) at System.Runtime.Serialization.DataContract.DataContractCriticalHelper.CreateDataContract(Int32 id, RuntimeTypeHandle typeHandle, Type type) at System.Runtime.Serialization.DataContract.DataContractCriticalHelper.GetDataContractSkipValidation(Int32 id, RuntimeTypeHandle typeHandle, Type type) at System.Runtime.Serialization.Json.DataContractJsonSerializer.get_RootContract() at System.Runtime.Serialization.Json.DataContractJsonSerializer.InternalIsStartObject(XmlReaderDelegator reader) at System.Runtime.Serialization.Json.DataContractJsonSerializer.InternalReadObject(XmlReaderDelegator xmlReader, Boolean verifyObjectName) at System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions(XmlReaderDelegator reader, Boolean verifyObjectName, DataContractResolver dataContractResolver) at System.Runtime.Serialization.Json.DataContractJsonSerializer.ReadObject(XmlDictionaryReader reader) at Inedo.Extensibility.ExtensionsVerifier.VerifyExtensionInternal(String bmxFileName, String shadowRoot, IEnumerable1 sdkAssemblyNames, AssemblyName coreAssemblyName, Version minimumAllowedVersion)`

I've checked the file permissions and "NETWORK SERVICE" has full control permissions to the extensions directory

Thanks
Simon

Hi @apxltd

Your description sounds perfect. Look forward to seeing this in a future version.

Also your software products rock! Keep up the great work!

Thanks

Simon

@stevedennis

Yes that is exactly what I was thinking except I would make it a 'user' level function vs 'feed'. I.E we don't want users creating different API keys for each feed that they manage.

We want one API key that gives them all the same access as their user account.

For example as a developer I have access to a nuget feed as well as a container image feed, I want to use a single API key to access both these feeds.

Simon

Hi @stevedennis

The user then needs an API key to use with CI/CD tools on the users workstation.

What tools, specifically? What permissions does this API key have?

Things like docker desktop, to connect to a proget docker feed you need to use Docker login proget.somehost.com which stores your credentials as a secret. These credentials are then used everytime you do docker pull proget.somehost.com/feed/containername:latest

You can use your AD credentials for this however if your password changes (which you're required to do every 60 days) you'll need to constantly update your docker login credentials. Or worse, your could have an automated deployment using these docker login credentials that is constantly locking out your ad account (as the stored password is now wrong)

The same thing can happen with the nuget package manger that is part of Visual Studio, inputing API credentials here in the below screenshot would make more sense:

Administrator needs to login to admin portal, add the ad user with the correct "security", then generate an API key and "impersonate" the user that has just been setup.

How often does this happen?

Everytime we have a new developer come on board that needs access to the Nuget feed.

If you impersonate an AD username, I would expect it to "just work" like logging in? Meaning, you don't need to set-up special privileges - just give the group? Is this not the case (maybe this is a bug)?

Can you give a specific case?

Apologies after more testing "impersonating" a user specified in an AD group works. However it does take an proget administrator to generate each api key for each user.

Thanks

Simon

Hey Guys,

Hoping to submit a feature request here.

In Proget you should provide the ability for a user to manage their own API keys via the web interface.

At the minute API keys need to be setup by an administrator and assigned to a user via the impersonate user field.

It would be nice if the user was able to create their own API key via the user menu here:

Use case:

Access to proget is setup using AD authentication and assigning an AD group (not ad user) with the correct privilege's.

The user then needs an API key to use with CI/CD tools on the users workstation.

Today:

Administrator needs to login to admin portal, add the ad user with the correct "security", then generate an API key and "impersonate" the user that has just been setup.

Required state:

User logs into the web portal and generates their own key that inherits the users current permission set.

Thanks

Simon

Hi @atripp

Just to let you know that I just upgraded version 5.3.24 and can confirm that this issue is now resolved!

Thanks so much for all your help!

Thanks

Simon

Awesome thanks @atripp

I'll wait for the 5.3.24 release. I'll let you know how testing goes!

Thanks

Simon

Thanks for the update @atripp

I await you're fix for this one. Let me know if I can be of anymore assistance.

Thanks

Simon