Supabase/Firebase onAuthStateChange [Listener on Browser and Event Trigger from server]

[dipeshhkc]

I came across a strange situation today. Let me explain it.

If we use Firebase/ Supabase as an authentication module for our project, we normally attach Auth Event listener in the browser (inside useEffect ) like

firebase.auth.onAuthStateChange() or supabase.auth.onAuthStateChange()

and if we trigger events like signup, signin, signout inside loader in remix which runs in server

supabase.auth.signIn() or firebase.auth.signIn()

The above listener will not trigger this signIn event since the listener is in the browser but signin event is happening inside the loader(server)

What's the recommended way of handling this?

[ccssmnn]

I'm no Remix-expert (yet :-)). The recommended way depends on what you want to achieve.

Firebase will signIn your users inside the browser with direct calls to Firebase Servers. If you need to load user data on the server, you should add a Cookie containing a JWT-Token. You should do this inside the onAuthStateChange-Callback.

Whenever you need to call an API, submit a form or similar tasks on a server, you should pass the JWT token to the action. Then use firebase-admin to validate the token, which will contain the user id.

I've spent some time with the firebase docs. Handling signIn-Forms with firebase auth is not supported, it seems.

[ccssmnn]

When you want to trigger server events, you could write a Component and Context which adds an event listener on its initial mount (useEffect(() => {...}, [])) and set up those event listeners there. These could then fire a fetch request to server endpoints. e.g.

import React, { createContext, useContext, useEffect, useState } from "react";
import { onAuthStateChanged, User } from "firebase/auth";
import { setCookie } from "nookies";
import { getInitializedAuth } from "~/client/auth";

const AuthContext = createContext<{ user: User | null }>({
  user: null,
});

export const AuthProvider: React.FC = ({ children }) => {
  const [user, setUser] = useState<User | null>(null);
  useEffect(() => {
    return onAuthStateChanged(getInitializedAuth(), async (user) => {
      // do something with user
      setUser(user);
    });
  }, []);
  return (
    <AuthContext.Provider value={{ user }}>{children}</AuthContext.Provider>
  );
};

export const useAuth = () => useContext(AuthContext);

Another Sign-In method is to create a session cookie and send it to the client. Remix' cookie management is a breeze, and firebase-admin allows the creation of session cookies which can last up to 2 weeks. docs here You will then notice sign-in, sign-out and other events on the server when creating, rejecting or deleting the cookie. A nice pattern for this is wrapping your loader. This could look like this:

export const protectedLoader =
  (loader: LoaderFunction): LoaderFunction =>
  async (params) => {
    const { request } = params;
    const session = await getSession(request.headers.get("cookie"));
    const { uid } = await verifyIdToken(session.get("idToken"));
    if (!uid) {
      console.info(`unauthorized request to ${params.request.url}`);
      return redirect("/");
    }
    return loader({
      ...params,
      params: {
        ...params.params,
        uid,
      },
    });
  };

// in your route

export const loader: LoaderFunction = protectedLoader(
  async ({ request, params }) => {
    const { uid } = params;
    // do something with uid
    return something
  }
);

[ch4nd4n]

I don't get it. That event is supposed to trigger on the client's browser, I don't understand how it can fire a change event on the server-side.