New "loginMethod" plugin extension

[lukasbestle]

It is now possible for plugins to register custom login methods for display in the login form:

Login method buttons with custom action:

panel.plugin("yourname/login", {
  loginMethods: {
    twitter: {
      label: "Twitter",
      icon: "twitter",
      action: function() {
        // your login handler
      }
    }
  }
});

Full form to switch between:

panel.plugin("yourname/login", {
  loginMethods: {
    customForm: {
      label: "Custom form",
      icon: "...",
      component: {
        template: `
          <!-- your login form code -->
        `
      }
    },
  }
});

The login methods can be enabled and sorted by the user like this in the config.php:

<?php

return [
  'auth.methods' => ['password', 'code', 'twitter']
];

@bastianallgeier The styling of the UI is a rough draft, feel free to change it.

[distantnative]

How about just naming it login or logins?

[lukasbestle]

@distantnative We already have login for replacing the whole login form and logins would honestly be too similar to that.

The reason I went with loginMethods is that the user-facing option also uses the term methods.

Is there anything in particular you think is not optimal about the naming?

[bastianallgeier]

@lukasbestle do our "native" login methods now also use the same mechanism? I.e. could you replace our email code login form with a plugin as well by overwriting it?

[bastianallgeier]

@distantnative @lukasbestle the name is fine for me. I tried to come up with something "better", but the only alternatives would be loginForms or loginScreens and they don't really match because it could also be just a redirect to an oauth endpoint. I agree that logins feels a bit too close to just login.

[distantnative]

Didn't have the other option in mind and thought it could be snappier (no camel-case). But agreed, with that option already in place logins would be too confusing.

[lukasbestle]

do our "native" login methods now also use the same mechanism? I.e. could you replace our email code login form with a plugin as well by overwriting it?

@bastianallgeier Short answer: No. Long answer: The plan for 3.5 is to have three separate plugin APIs for the different use-cases:

• Replacing or extending the whole login form
  This is the login extension in Vue we already have since 3.2.0 and will improve with #2929.
  Use-case: Theming (e.g. add a custom logo or additional information to the login page); of course the old feature of replacing the whole form will still work but the previous use-cases are now covered by the following features.
• Authentication challenge plugins
  There will be a backend plugin extension that allows registering custom authentication challenges next to our core EmailChallenge. This will be added in another PR in the next step.
  Use-case: Login with a Kirby user, but with other types of codes (TOTP, SMS, hardware tokens...).
• Login method plugins (this PR)
  Use-case: Completely different login forms that don't just use authentication codes, e.g. for OAuth (GitHub, Twitter...), LDAP (company networks)...

All three plugin APIs can be combined in the config.php. E.g. you could have a themed login form that allows login with a Kirby user and 2FA with an SMS challenge or via GitHub.

The reason why you can't overwrite the core login form itself is that the core form is tailor-built for 2FA, password-reset and login codes, so replacing it would break the second plugin API. You can however build your own login form with the third plugin API and then disable the core form in the config.php.

[bastianallgeier]

After checking it out a bit more, I really like the general implementation, but I'm afraid it still needs some more work. I'm not 100% sure how to solve it on the design side yet and I also think that the "Login via Email" "Login via Password" links above the email field should be removed when there are multiple login methods and they should be included in the list of login method buttons.

Let's move this to 3.5.x. We can easily introduce this in a patch release. The feature is 99% done. Does not introduce a breaking change and just needs a little more time.

[lukasbestle]

@bastianallgeier Makes sense! Feel free to continue with this however you like. :)

[bastianallgeier]

I think we need to revisit this after the Inertia changes, right?

[lukasbestle]

@bastianallgeier Either before or after, yes. So given we are already deep in Inertia refactoring, I think it makes sense to do this afterwards. :)

[bastianallgeier]

Can we archive this PR? I think we should rewrite it for Fiber. It looks to me like we can handle a lot of stuff for the login views on the backend now. We should also look into custom routes for each login method.

[lukasbestle]

I agree it makes sense to do as much as possible on the backend, although it should of course be possible to create custom Vue components for more complex login methods. In any case the current implementation cannot work with Fiber, so it needs changes.

If I remember correctly, you wanted to continue working on this feature, I haven't touched it since. Feel free to continue with this or close the PR as long as our discussion and the original idea don't get lost. The main goal of this PR was to show how the feature would work from a plugin dev and user perspective. The implementation and the design are parts where you definitely know better what the best way forward is.

[bastianallgeier]

I've added this to the 3.7 project. Let's see what happens if I close this. I hope it stays in the project.

[distantnative]

@lukasbestle I would be happy to help getting this back on track after Fiber. As far as I see it, this PR is the last thing missing from the plans outlined in https://github.com/getkirby/kirby/pull/2935#issuecomment-731087413, right? Or probably we need to revisit the custom login Vue component if that's still working with Fiber (at least I am not sure what the current status there is).

[lukasbestle]

@distantnative Your help is very welcome. :)

As far as I see it, this PR is the last thing missing from the plans outlined in https://github.com/getkirby/kirby/pull/2935#issuecomment-731087413, right?

Yes. The auth challenge extension API was merged in 3.5.0 and the login form extension was already supported since 3.2.0.

Or probably we need to revisit the custom login Vue component if that's still working with Fiber (at least I am not sure what the current status there is).

I haven't tested it since Fiber, but I think it should still be working. However I feel that most use cases were about custom login methods, which would be superseded by this new extension API. This would only leave theming for the existing login extension.

[distantnative]

@lukasbestle tried to wrap my head around it but somehow it's a bit all over the place right now with the several Vue components and where logic is hosted. We probably would need to consolidate this a bit more, but won't be able to do that in time for 3.7

[rasteiner]

While redesigning, a feature that could be useful would be the ability to disable certain methods for certain users. Like if a user has installed a passkey, it might be interesting to disable the password auth for that user only.

[lukasbestle]

@rasteiner With code challenges, this is already covered. But with whole login methods it's unfortunately impossible to do with a good UX. The login form doesn't know about the user before the email address is entered. The only thing it could do is to throw an error after successful login. This same behavior can already be achieved by deleting the .htpasswd file of the user account (which makes login with password impossible). I think this should cover your use case quite well – without having to add any additional configuration options.

[bastianallgeier]

I think it would be good to start this fresh at some point and move it to a lab branch in the meantime to close the PR.

[lukasbestle]

I feel like 90% of the code is no longer useful with Fiber. So only the feature idea and our concept discussions are valuable at this point.

Should we rather move this to Nolt?

[distantnative]

@lukasbestle sounds good

[lukasbestle]

https://kirby.nolt.io/553