I’m renew here. A couple of years ago I was toying with Phoenix, was clinging on to Go a bit too hard. This time, I’m hopefully here to stay.
I’m trying to evaluate phx.gen.auth. I would prefer not to have to write my own auth system, especially with security considerations in mind. However, there are some points I’m not clear about and I hope somebody can help me out
Item (1): Self-registration. This is something I don’t think I would ever need. Users will always be created by another user who has the right to do so and given permissions based on the role they play within the company. I assume I can just remove the registration route and self-registration will be gone, right?
Item (2): logging in via email link. This is a bit problematic for me as I live in a part of the world where Internet access is still a bit iffy for many companies. The best would be to just be able to log in with username/email and password. I saw a reference to a user settting somewhere, so I grepped config/* but without success. It looks like simply updating the login template, as well as the registration one to require a password should work. Or is there a better way? A simple configuration?
Item (3): Seeding. Each system would obvsiouly need an initial admin user to set up other users. I’m not sure how to go about that as I need to just add a user without it passing through the whole confirmation email workflow. How is this best done?
These points expose my lack of knowledge of Phoenix to be sure. But is phx.gen.auth the right solution for my needs or should i (I) look elsewhere or (II) roll my own?
For point 2, the password functionality is still there so you can just go through the generated code and remove all of the magic link stuff if you don’t want it.
For point 3, you could use a script, but Mix is not available if you use releases/docker/paas so it’s not the ideal approach. If this is a simple one-time thing you could always just manually seed the DB with psql.
If this is a service you will deploy many times (as your post seems to imply) then you could generate a special admin setup link with a long secret and persist it upon the first startup (e.g. when the users table is empty on startup). Then you just need to pass that URL to the admin; how exactly to do that is contextual.
Allowing the admin to set the user’s password is problematic as it implies the password must be transferred in plaintext somewhere.
Given that, you probably want some sort of “signup link” system where the admin creates a link like /register/<very long secret> which the user can enter their details into. You can just create a table for this in the DB and allow the admin to generate signup links.
You can then use the same system to seed the first signup link for the admin user, killing two birds with one stone.
I’ve outlined how I do invites here in a very low-touch way. I just re-purpose the confirmation token along with forgot password. I set a random password using :crypto.strong_rand_bytes(72) which I feel should be pretty safe… no?
Sounds reasonable to me. UX might be a bit worse than a dedicated invite system but for an internal tool I think most would consider that bikeshedding.
For those unaware, 72 bytes is the limit for bcrypt. Obviously that limit doesn’t apply to other hash functions. Realistically even 32 bytes of truly random entropy should be more than enough, though, so it doesn’t really matter here.
