Replies: 1 comment
-
You are right on! I agree with the requirements. It's certainly doable. The question is how to implement such without breaking the current plugin and config system. And who is willing to pay for the significant development 😉 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
The current authentication plugin mechanisms lack the capability of allowing a user to select an authentication provider. Verdaccio currently allows the configuration of many authentication providers, but merely tries them in order listed. This leads to overhead during the authentication process and failed login attempts on intermediate providers. Users should be able to select the authentication method used to login with on the web ui and create access tokens that can be used with the CLI clients.
Many authentication plugins exist for OAuth style logins. These plugins currently do a lot of heavy lifting in regards to modifying the way the web and server api function. The verdaccio-github-oauth-ui plugin, for example, modifies the Login button of the web ui so that clicking it takes the user directly to a GitHub login. The verdaccio-google-auth-ui-2 plugin, similarly does the same thing but for the Google Authentication endpoint instead. As such, these plugins cannot be used together to allow a user to login via Google or via GitHub as only one will work. The source code of these plugins reveals a lot of overlap in how they modify the ui and server api to handle authentication and ultimately demonstrate the lack of flexibility of the current authentication plugin model.
Additionally, there seems to be a little confusion with the authentication plugins about their true purpose. These plugins currently provide authorization in addition to authentication. In my opinion an authentication plugin should be limited to only authentication. All authorization mechanisms should likely be moved to separate plugins, if needed. Separation would allow a more streamlined authentication mechanism where any dialogs or prompts could be incorporated into the various different authentication methods as needed.
Beta Was this translation helpful? Give feedback.
All reactions