You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The original implementation of credentials providers was designed before API clients were introduced into the product.
The BasicAuthProvider uses a username and password to perform basic auth in exchange for an access token. Other subclasses of this provider that shipped are all available as top level imports in the package.
The other builtin providers inherit from BasicAuthProvider and creating API client versions means duplication of code and an unintuitive naming scheme. Plus, the top-level imports should be kept to a minimum.
Proposed
I am proposing a breaking change to the existing structure of the SDK's credentials providers and changing the subclasses to accept a credentials provider type to allow more flexibility and only one implementation of each type even if other authentication methods are introduced into the future.
Only the two base providers would be made available as top level imports.
The BasicAuthProvider would be renamed to UserCredentialsProvider to avoid confusion with basic auth - which Jamf Pro no longer supports for direct API authentication - and make the use of a user account clear.
The PromptForCredentials, LoadFromAwsSecretsManager, and LoadFromKeychain providers will be removed and replaced with helper utilities that return an instantiated credentials provider of the specified type.
The documentation will need an expanded section in the "Getting Started" guide and "SDK Reference" better explaining importing and using all of the available credentials providers and helper utils.
The text was updated successfully, but these errors were encountered:
Current
The original implementation of credentials providers was designed before API clients were introduced into the product.
The
BasicAuthProvider
uses a username and password to perform basic auth in exchange for an access token. Other subclasses of this provider that shipped are all available as top level imports in the package.Later, the
ApiClientCredentialsProvider
was added to support API clients. It, along with all providers, is available at a lower level import.The other builtin providers inherit from
BasicAuthProvider
and creating API client versions means duplication of code and an unintuitive naming scheme. Plus, the top-level imports should be kept to a minimum.Proposed
I am proposing a breaking change to the existing structure of the SDK's credentials providers and changing the subclasses to accept a credentials provider type to allow more flexibility and only one implementation of each type even if other authentication methods are introduced into the future.
Only the two base providers would be made available as top level imports.
The
BasicAuthProvider
would be renamed toUserCredentialsProvider
to avoid confusion with basic auth - which Jamf Pro no longer supports for direct API authentication - and make the use of a user account clear.The
PromptForCredentials
,LoadFromAwsSecretsManager
, andLoadFromKeychain
providers will be removed and replaced with helper utilities that return an instantiated credentials provider of the specified type.The documentation will need an expanded section in the "Getting Started" guide and "SDK Reference" better explaining importing and using all of the available credentials providers and helper utils.
The text was updated successfully, but these errors were encountered: