The permissions system in ProGet is contra-intuitive and potentially dangerous.
Lets assume a case with 3 users A, B, C and 2 repositories R1, R2. All users are in the Active Directory/LDAP backend.
- User A does not have any custom permissions set.
- User B does have (Admin/devel) permissions to R1, no permission set to R2.
- User C does have deny admin permissions to R1 and admin permissions to R2.
Case: User A browses to the local ProGet site.
Expected outcome: A can view the site, but does not see any feeds and does not have a way to determine the name of feeds of the system.
What actually happens in ProGet: A can view the site, sees some links containing feed names, but many lead to 500 error pages.
Case: User B browses to the local ProGet site.
Expected outcome: B can view and upload packages for R1, but cannot find out there is a repo R2.
What actually happens in ProGet: B can view the site, maybe sees a broken link with another feed name in it, but cannot actually upload any packages, because of Error 500. This is because no entry with Deny for R2 has been created.
Case: The administrator adds a new feed R3 to the ProGet repository and grants A developer permissions to R3.
Expected outcome: A can now download and publish packages to R3.
What actually happens in ProGet: The system breaks for the unrelated users B, C; they are confronted with 500 errors.
A possible solution might be to give (system) permissions to everyone, then add Deny entries.
This is not recommended because this means that:
- on every change in the feed layout, all users permissions have to be updated. As soon as there are more than a handful of users, the effort to do this quickly becomes prohibitive.
- Deny entries are managed separately from Grant. This means it's easy to forget one or the other. ProGet breaks down for the user for some of these cases, but not for all (remove Grant, do not remove Deny -> breaks. Remove Deny, do not remove Grant -> does not break).
But the most important problem is that a change to one part of the system (adding a feed visible for A alone) breaks the system in other parts (users B and C on repos R1 and R2).
The cause of this weird and unintuitive behavior seems to be the handling of the "No permissions" case.
The expected behavior would be to require an entry to to get access to something, and denying access otherwise.
ProGet insists that we
- Create an Entry granting Access to the item that should be invisible.
- Create an Entry that denies the access to the item.
If we do not follow this approach, ProGet fails to function properly and throws error 500 pages.
This is less a support request than a request to fix the behavior. An important reason why people buy ProGet is that it offers authentication to NuGet feeds, that is, to limit access to them. I feel that the way the permissions system was designed hinders this purpose, because it makes administration more complex and error prone.