Support email link authentication with Firebase

[doesnotexist]

Upgrade Guide
For existing redwood projects using firebase auth, make the following changes to your project:

1. update dependency in web/package.json to "firebase": "^9.0.2",
2. update dependency in api/package.json to firebase-admin": "^9.11.1"
3. Modify initialization for AuthProvider with firebase client to pass an object with required firebaseAuth property and optionally firebaseApp property as shown here:

// App.tsx
...
import { initializeApp, getApps, getApp } from '@firebase/app'
import * as firebaseAuth from '@firebase/auth'
...
const firebaseConfig = {
  apiKey: process.env.FIREBASE_API_KEY,
  authDomain: process.env.FIREBASE_AUTH_DOMAIN,
  databaseURL: process.env.FIREBASE_DATABASE_URL,
  projectId: process.env.FIREBASE_PROJECT_ID,
  storageBucket: process.env.FIREBASE_STORAGE_BUCKET,
  messagingSenderId: process.env.FIREBASE_MESSAGING_SENDER_ID,
  appId: process.env.FIREBASE_APP_ID,
}

const firebaseApp = ((config) => {
  const apps = getApps()
  if (!apps.length) {
    initializeApp(config)
  }
  return getApp()
})(firebaseConfig)

export const firebaseClient = {
  firebaseAuth,
  firebaseApp,
}

const App = () => (
  <FatalErrorBoundary page={FatalErrorPage}>
    <RedwoodProvider titleTemplate="%PageTitle | %AppTitle">
      <AuthProvider client={firebaseClient} type={'firebase'}>
        <RedwoodApolloProvider>
          <Routes />
        </RedwoodApolloProvider>
      </AuthProvider>
    </RedwoodProvider>
  </FatalErrorBoundary>
)

NOTE If you use v8 firebase sdk elsewhere in your app's code then in those places you would import compat versions from v9 firebase sdk to maintain code compatibility, see docs:
https://firebase.google.com/docs/web/modular-upgrade

---

firebase auth: support email link authentication

• Also updates firebase dependency to v9 (modular sdk)
• Associated changes to generator 'yarn rw setup auth firebase'
• Adds token decoder for api side verification of auth tokens

Closes #3346
Closes #3344
Closes #3323
Closes #2260

It is the app's responsibility to send the email link to the user either using firebase's sendSignInLinkToEmail() where firebase sends the email for you or by using generateSignInWithEmailLink() to send it in a more customized email with some other email sending service or SMTP server.

The email link sent the user will ultimately redirect to your app and firebase expects you to handle the users login when they arrive at this URL which you specify with
acitonCodeSettings argument to the method generating/sending the email link.

const actionCodeSettings = {
  // URL you want to redirect back to. The domain (www.example.com) for this
  // URL must be in the authorized domains list in the Firebase Console.
  url: `${process.env.URL}/email-signin`,
  handleCodeInApp: true,
}

The handler at this url can then call the AuthProvider's logIn() method with

1. options.providerId === 'emailLink'
2. options.email with the user's email address
3. options.emailLink with the URL and url params received at the handler/route for the URL specified in the actionCodesSettings.

Here's an example page component for handling email link authentication

import { useEffect } from 'react'
import { Redirect, routes } from '@redwoodjs/router'
import { useAuth } from '@redwoodjs/auth'

const EmailSigninPage = () => {
  const { loading, hasError, error, logIn } = useAuth()

  const email = window.localStorage.getItem('emailForSignIn')
  // TODO prompt the user for email if its not available... email Link opened on different device

  const emailLink = window.location.href

  useEffect(() => {
    logIn({
      providerId: 'emailLink',
      email,
      emailLink,
    })
  }, [])

  if (loading) {
    // TODO animation goes here
    return <div>Auth Loading...</div>
  }

  if (hasError) {
    console.error('HasError is set')
    if (error) {
      console.error(error)
    }
    return <div>Auth Error... check console</div>
  }

  return <Redirect to={routes.home()} />
}

export default EmailSigninPage

[viperfx]

Nice work! I use firebase myself and do some custom stuff with magic login via custom tokens.

I am curious what is the user flow like for email authentication? and how is it different generating a custom token and sending via email?

[doesnotexist]

@viperfx I think it's pretty similar and it would be very similar execution path for supporting custom token in the auth client, say by checking if providerId = 'customToken' and passing the token via an optional customToken property on the options object for the login/signup methods.

To synchronize login state across browser tabs, my app has a component that subscribes to onAuthStateChanged events and trigger's the AuthProvider's reauthenticate() whenever the firebase auth state changes. like so:

import React from 'react'
import { AuthContext } from '@redwoodjs/auth/dist/AuthProvider'

import { getAuth } from '@firebase/auth'

export class FirebaseAuthSubscriber extends React.Component {
  private unsubscribe?: () => void

  constructor(props) {
    super(props)
    this.unsubscribe = null
  }

  async componentDidMount() {
    let initial = true
    this.unsubscribe = getAuth().onAuthStateChanged(() => {
      if (!initial) {
        // initial state change on page load, already handled in restoreAuthState()
        this.context.reauthenticate()
      }
      initial = false
    })
  }

  componentWillUnmount() {
    if (this.unsubscribe) {
      this.unsubscribe()
      this.unsubscribe = null
    }
  }

  render() {
    return this.props.children
  }
}
FirebaseAuthSubscriber.contextType = AuthContext

[viperfx]

Thanks for the detailed reply! Looks interesting. We built our own magic sign in method on top of firebase, but this might be worth exploring.

One question I had is - does firebase handle the email sending? I wonder if it's possible to use your own backend to create the link and send email using our own provider.

[doesnotexist]

@viperfx It's your choice as the whether firebase sends the email for you or you send it.

If you app calls sendSignInLinkToEmail() then firebase sends an email for you.

If you call generateSignInWithEmailLink() you can put the generated link in your own custom email and send it through your own mail service or SMTP server.
https://firebase.google.com/docs/auth/admin/email-action-links#generate_email_link_for_sign-in

[thedavidprice]

Note: this includes an upgrade to v9 and will fix an existing bug.

[dac09]

Thanks @doesnotexist for this! Can you confirm that the token is still refreshed once it expires?

[doesnotexist]

@dac09 > Thanks @doesnotexist for this! Can you confirm that the token is still refreshed once it expires?

It doesn't seem that the redwood AuthProvider/AuthClient needs to be aware of refreshing beyond what is done in getToken() since firebase's sdk handles refresh when getIdToken() is called it will refresh the token if it's expiring or close to expiring.

[doesnotexist]

I have a hunch that "return undefined" is probably not idiomatic typescript/javascript. I only put this here to get rid of warning in the IDE about some execution paths having no return.

[doesnotexist]

As far as I can tell this is no longer the case, but I'm not sure, what would be a good test to confirm that removing repackagePromise has not changed this w.r.t. try {await} catch blocks / exception handling?

[doesnotexist]

I attempted it but it opened up a bunch of typescript hurdles that I wasn't prepared to address.

[doesnotexist]

@dac09

I like this change a lot @doesnotexist, good thinking! Will give it another round tomorrow morning!

Actually, this is not going to work because it breaks "yarn rw build" for projects that don't use the firebase auth client and do not have firebase as a dependency in their web/package.json.
The webpack development server gracefully pushes past the error and splashes an overlay about the build error that reads

Error:
Module not found: Error: Can't resolve '@firebase/auth' in '<project dir>/node_modules/@redwoodjs/auth/dist/authClients'" 

The other way is a bit uglier and introduces that breaking change since the authclient is initialized differently but it doesn't break projects that aren't using firebase auth or require them to introduce a dependency they do not need. So I'm reverting this change back to the other way.

[dac09]

Hey @doesnotexist - could you help me understand something?

Why do we need to do this, and whats the difference between the object returned from getAuth, and the imported import * as firebaseAuth from '@firebase/auth'?

[doesnotexist]

Sure @dac09

The reason is to avoid firebase dependency for normal redwood projects that are not using the firebase auth provider. Instead, users who are using firebase auth, are required to pass the module to this factory function so it can call the associated functions. One export is the getAuth() method which returns the auth object (or creates and initializes an auth object) for the firebase app or the default firebase app if no app is given. In VS Code, it might help to look at the autocomplete suggests after typing firebaseAuth vs the auth object returned from getAuth().

The reason this looks so much different than before has to do with the firebase v8 to v9 transition which reorganized and split the firebase sdk into submodules with the goal of supporting tree-shaking. Previously there was one monolithic firebase import and firebase app instances had a method attached that produced the associated firebase auth instance v8: firebaseApp.auth()
v9: equivalent is getAuth(app?) which is now a module export in the @firebase/auth module

One thing I think is confusing about what I've written is, though similarly named there is a distinction between the two properties in the FirebaseClient type, firebaseApp is an instance (usually created/initialized in App.jsx by calling @firebase/app's initializeApp() method) whereas firebaseAuth is the module exports object from @firebase/auth and not a firebase auth instance.

[doesnotexist]

Also, I should mention that it isn't sufficient to just pass the auth instance into this factory function, because there are multiple other functions needed from the module which no longer live as methods on an auth instance but are just exports from the module. So even if we passed an auth instance we'd still need to pass in the module.exports from @firebase/auth in order to call those other functions without putting an import ... @firebase/auth in this file and causing non firebase auth projects to have an unneeded firebase dependency in their web/packages.json

[dac09]

I tried something else see commit here: a47974e

And we pass it to the auth provider like so:

const firebaseApp = ((config) => {
  const apps = getApps()
  if (!apps.length) {
    initializeApp(config)
  }
  return getApp()
})(firebaseConfig)

const App = () => (
//...
    <RedwoodProvider titleTemplate="%PageTitle | %AppTitle">
      <AuthProvider client={firebaseApp} type="firebase">

What do you think? This seems to work and simplifies the setup code in App.tsx

[dac09]

Also I worked out the difference - getAuth gives you an instance of the auth client. Where as the imports are just utility functions, so maybe there's no need to pass it through from the app level right?

[doesnotexist]

I also prefer a47974e and I tried similar with 70c59e6 but had to revert it back to passing the module exports because when I did create-redwood-app and then 'yarn rw dev' the default app had a compile error.
Described here: #3347 (comment)

Have you tried create-redwood-app with your changes? I think you might run into the same issue

Also, early on I was passing an object with only those exported utility functions before, which might be more ideal from tree-shaking but required a new typescript type to describe the subset of functions required from @firebase/auth's modules.export ... But perhaps thats ok, I was a less familiar with typescript back when I was doing that.

[dac09]

Thanks so much for all the effort into this @doesnotexist

Approving, but definitely one for us to revisit when we think about changing how the auth packages are managed, so that we don't have to "inject" firebaseAuth imports!

[thedavidprice]

Phenomenal effort on this one @doesnotexist

I'll make sure we include your "Upgrade Guide" (from OP) in the Release Notes for v0.37.

And I'll also be updating the All Contributors and Readme this week!