I agree to having an is_active flag. Do you create users before confirmation in your apps? Do you have a flow that is like, "Hey, wanna join, enter your email" form collecting email -> create temp user with email, isactive=false, and token -> send email with button to confirm -> when user clicks on button -> go to website with token and get redirected to form collecting rest of stuff ?
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
My situation's a bit different since the stuff I work on is all enterprise software. We recently offloaded all our user management onto a single sign-on provider, but before that we did collect their information on signup and send them an activation/password reset email with a token (token hash and expiry stored in the database for verification). We didn't have a second stage, but then we weren't charging individual users.
Thanks for your comment, Dian!
I agree to having an
is_activeflag. Do you create users before confirmation in your apps? Do you have a flow that is like, "Hey, wanna join, enter your email"form collecting email-> create temp user with email, isactive=false, and token -> send email with button to confirm -> when user clicks on button -> go to website with token and get redirected toform collecting rest of stuff?My situation's a bit different since the stuff I work on is all enterprise software. We recently offloaded all our user management onto a single sign-on provider, but before that we did collect their information on signup and send them an activation/password reset email with a token (token hash and expiry stored in the database for verification). We didn't have a second stage, but then we weren't charging individual users.
Thanks for sharing your experience!