lcabrini
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?
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Deploy Phoenix to your own VPS with PaaS ease: push-to-deploy, zero downtime, auto SSL, managed Postgres. 14-day free trial at potions.io
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First 7 of 7 Posts
lcabrini
So, I think I’ve figured Item (1) out. At least I’ve got rid of the registration links. Next is allowing an admin to be able to create users.
garrison
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
userstable is empty on startup). Then you just need to pass that URL to the admin; how exactly to do that is contextual.garrison
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.
lud
To create admins manually you can also open a remote shell into your production app and do it from there.
sodapopcan
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?garrison
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.
lcabrini
Thanks to all for the feedback. I’m going to stick with phx.gen.auth and am gradually working my way through it.