Using ProGet: Package Level Filtering for Infragistics Customers

Joshua Lezmi / Wednesday, December 5, 2018

General Purpose:

Since launching 16.2, Infragistics has provided NuGet packages across all of our UI controls for licensed users through our package repository; we have been using ProGet from Inedo to manage our packages in two core scenarios. In this post, we will discuss how ProGet helped us achieve package level filtering on feeds that only Infragistics customers should be allowed access to. 

The Problem:

We want to expose our private NuGet feed to our customers that have active subscriptions and provide a URL that we could declare publicly, but one that only licensed customers have access to. We also wish to avoid performing extra work (such as creating and managing new accounts for a third-party service). Customers should only need their Infragistics credentials to utilize Infragistics content.  

We also need to restrict the packages they can browse to the products and versions that they’ve paid for.  Hosting private feeds usually requires an all-or-nothing approach to feed management. Meaning, you either see all of the packages or you don’t see any of them. Access to the feed is also generally set by the feed owners in advance. We want to make it as frictionless as possible for a customer to access our feed; needing to create an account and get someone at Infragistics to assign permissions would not be so seamless. 

What Does ProGet Provide to Resolve This Issue:

ProGet provides extension support that allows us to insert functionality into the process that browses for packages on the feed.  If the feed “customers” were members of the Infragistics organization, the built-in ActiveDirectoryfunctionality provided by ProGet would work.  Since our customers are not part of the Infragistics organization, we needed a solution that would work outside of the ActiveDirectory. Fortunately, we can inherit the required functionality and override the authentication behavior to suit our needs. 

How We Did It:

  1. Created a simple class library project 
  2. Included the Inedo.SDK NuGet package as a dependency 
  3. Created a custom UserDirectory class to handle our own authentication: 
    • Inherited from the Inedo.Extensibility.UserDirectories.UserDirectory class 
    • Overrode methods that handle the user’s registration and create new ProGet users as required. 
    • Created users inside the Proget database in order to store the users. 
  4. Once the user has access to ProGet and our feed, our custom package filtering took over: 
    • Created a class that overrode Inedo.Extensibility.PackageFilters.PackageFilter 
    • We overrode the IsPackageIncluded method and performed our own logic to determine if a package is relevant for that user. Since users are authenticated with their accounts, we knew what products and versions they had purchased. We compared this with our package names, version numbers, and release dates to determine if it would be included in the customer’s list.  
  5. Once our project was compiled and an *.inedox(*.progetx) file was generated, placing that file inside the ProGet extension folder showed our extension in the ‘Manager Extension’ page. 
  6. Once the extension was loaded by the Proget, our custom directory showed at the ‘Change User Directory’ dialog and we simply switched to it.