Sometimes the easiest stuff takes me 10 times longer to implement than it would for pretty much any other developer out there.

Exhibit A: authentication with Google’s Firebase. I have probably written about this before, but regardless I’ll provide a crash course overview of the story up ’till now.

Firebase is a suite of services offered by Google that has two things going for it. One, it’s free to a generous point. Two, it’s pretty easy to implement if you’re anyone but me. Firebase offers user management meaning with Firebase Auth, I can register users by email and password, federated logins via OAuth providers like Twitter and Google itself, or use a custom system. Firebase will store the users, their passwords, and deal with some very light user account management functionality. The benefit to this is that I don’t have to create the infrastructure for proper registration and authentication, nor do I have to store the credentials myself. Plus, I can use the SDK on both the client and server so using access tokens is super easy. However, I was having a hard time dealing with the usual web flow of events because of one weird quirk of Firebase.

First, the roadmap. Consider a standard application on the Internet these days. When you first arrive, you register with a username and password. Then you get an email in your inbox with a link you have to click. This ensures that the email you entered during registration actually belongs to you. Once you land on the site as a result of said link, your account is now authorized and ready for use. But wait! You don’t come back for six months and at that time you’ve forgotten your password. You click the “Reset password” link on the login page, and you get another email with another link. Clicking on that link sends you to a page where you can enter a new password (twice so you don’t fat-finger it!). Once you do this, your password has been reset and you are ready to go!

According to Firebase, this is a 16-step process all told. Well, maybe fewer steps than that, but not by much. I was having a hell of a time wrapping my head around the files I would need to create to accomodate:

1. Registration.
2. “Check your email” page after registration.
3. “Email verified!” page after clicking the email link.
4. “Enter your email” page for resetting a password.
5. “Check your email” page after entering your email to reset your password.
6. “Choose a new password” page after clicking the email link
7. “Password changed!” page for acknowledging the success.
8. All kinds of “something went wrong” pages
9. Login
10. Log out

Firebase offers methods in their SDK that actually do things like creating accounts with just an email and password, sending emails for various things, and handling password changes, but the emails that their system sends…those were the pain points because they all use the same link, differing in purpose by the single query string parameter “mode”. Items 2, 3, 4, 5, and 6 had to be the same component in order for the link in the email to work, and that was seriously messing with my head. I got it eventually, but it took far longer than it should have.

I have written entire CRM systems from whole cloth in the past, but for some reason this was giving me headaches. That one, single landing page for all emails, regardless of whether it’s an account verification or password change authorization, was making things a lot more difficult than it should have been. In Firebase’s defense, I could (and should) use a third-party system through which to send emails if for no other reason than I can actually tailor the email sent to users (Firebase uses a weak text-only template which works for testing, but not much else). Using a third-party I could also use different emails for handling account verification and for password change requests. Thing is, I will need to do this eventually, making this PITA process completely self-inflicted.