Configurable Login Button

[n4bb12]

Hey all, I've got a Plugin API feature request. I'd be happy to provide the nesessary PRs once we've agreed what would be a good way to implement this 🦝

Is your feature request related to a problem?

Currently, adding server-side authentication providers is pretty doable with the auth plugin API.
When you're trying to modify the login button, however, things are a bit more difficult.

When and why would UI login components need to be changed?

• For an OAuth scenario, a username/password login form doesn't make much sense.
• Combining multiple auth plugins, such as GitHub + GitLab + LDAP requires more than one login button.
• In a reverse proxy login scenario (see this issue), a login button is not required at all and it would not provide any useful functionality.
• If you want the login form + something else, it's not easy to achieve.
• The displayed usage instructions are misleading when using non-default auth plugins.

Why is it hard to change UI login components?

• It currently requires patching responses, hijacking klicks and hardcoding selectors. This is brittle and cumbersome.
• There is no server-side API for configuring the login components on the UI in a maintainable and documented way.
• A plugin that interferes with the frontend session also needs to know implementation details such as which localStorage values to clear/write, or how the JWT needs to be created.
• Most of this is not part of the official plugin API, so things can break easily and unnoticed.
• Once a UI implementation detail changes, it requires extra work for plugin authors to keep the plugin backward-compatible.

Describe the solution you'd like

Option A)

• Change the current login button/form to a dedicated login page.

This change would make things a lot easier because it would allow plugins authors to replace the login page with something that makes sense for the plugin without requiring any hacks. It's also the solution that requires the least work.

The downside is that combining multiple auth plugins is still not straightforward.

Option B)

• Extend the server-side auth plugin API with additional methods to collect "UI login configuration". This could be information such as whether the default login button should be rendered and which new login buttons to add, with configurable text, icon, color and href.
• Add a new endpoint to the verdaccio API that returns this information.
• Fetch the login configuration on the UI and render the login components accordingly.

This solution requires a bit more work but has several advantages. Auth plugins can be easily combined. Plugin authors don't need to worry about UI session-related implementation details. The amount of work to implement an auth plugin that also works on the UI is much less work.

Option C)

A solution for this could also be implemented in a "base" plugin that provides the necessary extra APIs and does all the ugly work. Auth plugins could then hook into the base plugin instead.

However, this puts great responsibility on the author of this plugin and might backfire long-term.

Describe alternatives you've considered

• Hack the UI - Example A, B, C
• Leave the original UI untouched and just add behaviour. This is not too great for the user. The default login UI might no longer work as expected or become useless. Displayed information might be incorrect or misleading.

Thanks in advance 🎈

[juanpicado]

Thanks for this, I read it roughly and still need more time to reply. We are planning breaking changes for plugins in v5 so might the best moment to do it.

[n4bb12]

Sounds good, what's planned for v5?

[juanpicado]

I will share a full plan end of the month (🤞 ), a sum of request and wishes we have around here, so anyone can contribute with a clear direction where we are going. As heads up, breaking changes on plugins, we need to think in a better approach.

[juanpicado]

cc: @priscilawebdev here the use case about login button