There's a problem with this if you log in with one user, then log in again as another user, it doesn't refresh and still uses the old user.

@pashpashpash hmmmm, that's odd. What browser are you using? Are you seeing a problem with the service worker?

I did guard the router refresh behind the service worker ready & so I could ensure auth state was in sync with the new magic url method.

I should do the same with login, only allow it if the service worker is registered and ready—since we rely on that.

@pashpashpash hmmmm, that's odd. What browser are you using? Are you seeing a problem with the service worker?

I did guard the router refresh behind the service worker ready & so I could ensure auth state was in sync with the new magic url method.

I should do the same with login, only allow it if the service worker is registered and ready—since we rely on that.

I'm on Chrome. It would also be helpful to have some documentation on the flows between the service worker, the client, and the server side rendering processes. I.e. if the server renders conditionally based on currentUser, but that user changes, will the page reload? Or will we need to include a reload in the clientside code. Explaining what we should expect. Thanks!

Another issue I found is that server actions seem to drop the current user (currentUser=null), even though when SSR'ing a page that later calls the server action, the server says there is a currentUser.

Yeah, upon further inspection, it looks like server actions are sent as POST requests, which in your service worker setup:

self.addEventListener("fetch", (event) => {
  const { origin, pathname } = new URL(event.request.url);
  if (origin !== self.location.origin) return;

  // Use a magic URL to ensure that auth state is in sync between
  // the client and the service worker
  if (pathname.startsWith("/__/auth/wait/")) {
    const uid = pathname.split("/").at(-1);
    event.respondWith(waitForMatchingUid(uid));
    return;
  }

  if (pathname.startsWith("/_next/")) return;

  // Don't add headers to non-GET requests or those with an extension
  // This helps with CSS, images, fonts, JSON, etc.
  if (event.request.method !== "GET" || pathname.includes(".")) return;

  event.respondWith(fetchWithFirebaseHeaders(event.request));
});

Means that the firebase auth headers are not included in the request. So, naturally, the action tries to run:
const { firebaseServerApp, currentUser } = await getAuthenticatedAppForUser();

And gets currentUser === null.

@jamesdaniels Okay I fixed this by allowing POST as well as GET requests in your service worker fetch event listener:

self.addEventListener("fetch", (event) => {
  const { origin, pathname } = new URL(event.request.url);
  if (origin !== self.location.origin) return;

  // Use a magic URL to ensure that auth state is in sync between
  // the client and the service worker
  if (pathname.startsWith("/__/auth/wait/")) {
    const uid = pathname.split("/").at(-1);
    event.respondWith(waitForMatchingUid(uid));
    return;
  }

  if (pathname.startsWith("/_next/")) return;

  // Don't add headers to non-GET/POST requests or those with an extension
  // This helps with CSS, images, fonts, JSON, etc.
  if ((event.request.method === "GET" || event.request.method === "POST") && !pathname.includes(".")) {
    event.respondWith(fetchWithFirebaseHeaders(event.request));
  }
});

Please let me know if this is bad practice. But it seems to work fine. Idk

@pashpashpash good catch thanks, i'll address that

Sorry to keep bugging you, but I'm still getting a weird bug where the auth state randomly tells me that the current user is null, when attempting a server action.

Example scenario:

1. User clicks on a button on the client that fetches a server action
2. Server action calls const { firebaseServerApp, currentUser } = await getAuthenticatedAppForUser();, currentUser is authenticated and works fine.
3. User clicks on the button x amount of times again, and it works fine, user is authenticated
4. User clicks on the button, and all of a sudden, currentUser is null and the server action fails.
5. User clicks on the button right after that failure (no page reload), and it works fine again.

The most frustrating part about this bug is it seemingly happens at random, it feels ephemeral. Often the button works fine, and subsequent button clicks with other server actions are authenticated. But then randomly later on it shows the user as unauthenticated again. No page refreshes or anything. Same page, just a different point in time.

EDIT:
FYI: After some debugging, I was able to fix this by just retrying to get the authIdToken if the first time I tried it was null, i try 2 more times with a 0.25s sleep. Not sure why but it fixed the issue.

async function fetchWithFirebaseHeaders(request) {
  let authIdToken = await getAuthIdToken();
  if (!authIdToken) {
    // sleep for 0.25s
    await new Promise((resolve) => setTimeout(resolve, 250));
    authIdToken = await getAuthIdToken();
  }
  if (!authIdToken) {
    // sleep for 0.25s
    await new Promise((resolve) => setTimeout(resolve, 250));
    authIdToken = await getAuthIdToken();
  }
  if (authIdToken) {
    const headers = new Headers(request.headers);
    headers.append("Authorization", `Bearer ${authIdToken}`);
    request = new Request(request, { headers });
  }
  return await fetch(request).catch((reason) => {
    console.error(reason);
    return new Response("Fail.", {
      status: 500,
      headers: { "Content-Type": "text/html" },
    });
  });
}