Allow auth / login via code with any mail address from a given domain? Possible?

Kirby 3 Questions 🤔
#1

Hi all,

I’m looking to give each user account a protected landing page with personalized content (only viewable to this specific account). In terms of a friction-less experience a login with code would be ideal.

…the cherry on top (which I am looking for) would be if the url could be shared within an organization, so that it is valid with any address as long as the specified domain matches. I’ve seen this with slack or miro in conjunction with team invites where the measure is if the one trying to login has access to a dedicated domain.

Is this possible with the current release of kirby?

Looking forward to any answers :slight_smile:

#2

With different email addresses, I don’t know.

#3

Thanks, I found the linked guide but couldn’t quite make out if it answers my question :see_no_evil:

Just to clarify: if the account mail address is: “info@kirbyrocks.com” I’d like it to also accept “steve” and “judy” @kirbyrocks.com.

#4

Yes, I understand that, but since for all the methods in the guide the user email seems to be required, I don’t think different email addresses will work.

But @lukasbestle can certainly tell you more.

You can - of course - always set up your own authentication logic.

#5

Thanks @texnixe — looking forward to his answer. In the meantime I’ll give the topic some more thought.

#6

It is currently not possible to log in to a single Kirby user account using multiple email addresses.

Do the users need access to the Panel or is this a frontend-only thing? Because that could be done.

#7

Thank you very much for your answer @lukasbestle. In fact, they do not need panel access — not at all. Could you maybe outline the “that could be done part”? :blush:

#8

You possibly could create users on the fly if they match certain business rules? (like if the email domain is xyz)

I think you could do that with user.login:before and then, if your rules validate impersonate and create a user.

And if you would do your own frontend login you even don’t need the hook, you just can create the user and login the user yourself. $user->login($password) or with passwordless login.

Ofcourse this entire setup is super vulnerable because of the lack of email validation. You can setup your own logic for that or “abuse” the reset password functionality. (create user on the fly if business rule validates and trigger the reset the password so user can reset password and login afterwards)

Or use the code validation so they will receive a mail with the code to login.

Just thinking out loud here obviously :sweat_smile: Haven’t done any of those things yet :grimacing:

#9

Wow @samzzi! Thanks for your input and inspiration :slight_smile: That definitely gives me some ideas. Authentication via code is my currently preferred as I find it most elegant. As I’m just getting started with this kirby site I’ll have to look up a few things and keep thinking a bit more.

Thanks again and have a great day :raised_hands:

#10

The route that Sam has explained above is what I had in mind as well. In your login controller you could do something like this:

  1. If there is already a user with the entered email address, create an authentication challenge directly.
  2. Otherwise, check that the domain of the email address matches the allowed domain.
  3. If it does, create a user with $kirby->users()->create() (you don’t need to pass most of the options) and then immediately create an authentication challenge for them.
#11

Just wanted to give a short update that I was able to implement the idea successfully, so that now anyone with the same domain can login via code if the domain is known (meaning, at least one registered user with that domain exists).

Obviously, non unique domains such as “gmail” are a problem to think of. I went the easy/practical solution and kindly ask them to request access via contact, if the mail address is not known (if they are, they just proceed to the code). For my setup it’s an edge case but I thought it would be nice to have it anyway due to being more versatile.

In addition to your ideas @samzzi & @lukasbestle the thread below and the working case within from Anthony1 where a huge help.

Cheers :raised_hands:

1 Like