cloudflare-next-intl 0.8.27 → 0.8.29

package/dist/src/firebase_auth/middleware/update_session.js

@@ -369,23 +369,35 @@ export default async function updateSession(request, baseResponse, locale, rebui
     }
     let unverifiedEmail = false;
     if (fa.verifyEmailPath && !isVerifyEmailPage && hasSession && decodeJwtPayload(token)?.email_verified === false) {
+        // Sending a user to `verifyEmailPath` is only safe when this claim
+        // reflects the LIVE account state, because that page resolves the
+        // same user through `getAuthUser()`/`initializeServerApp` — which
+        // reads the Auth service directly, not this frozen claim — and
+        // redirects home the moment it sees a verified user. Any disagreement
+        // between the two is therefore not a stale-data annoyance but an
+        // infinite redirect loop.
+        //
+        // The hint cookie cannot settle that: it is a client-written mirror,
+        // and after the user verifies in another tab (or the client simply
+        // never re-runs) it keeps asserting a `false` that is now wrong,
+        // while the Auth service already reports verified. Trusting a
+        // `'false'` hint as confirmation is exactly what pinned verified
+        // users in the loop. So the hint is only ever allowed to SKIP work
+        // when it agrees the user is verified — never to prove they aren't.
         const hint = request.cookies.get(emailVerifiedHintCookieName)?.value;
-        const hintConfirms = hint === 'false';
-        if (!hintConfirms && !refreshedToken) {
+        if (!refreshedToken) {
             const refreshToken = request.cookies.get(refreshTokenCookieName)?.value;
             if (refreshToken) {
-                const result = await refreshIdToken(fa.apiKey, refreshToken);
+                // `skipCache`: the cached entry is what produced the very
+                // token whose claim is in question, so a cached refresh can
+                // hand back that same token and confirm nothing.
+                const result = await refreshIdToken(fa.apiKey, refreshToken, { skipCache: true });
                 if (result.status === 'refreshed') {
                     refreshedToken = { idToken: result.idToken, refreshToken: result.refreshToken };
                     token = refreshedToken.idToken;
-                    // The hint can say `true` (client already confirmed
-                    // verification live) while this refreshed claim still
-                    // says `false` — token-claim propagation on Google's
-                    // backend can lag behind the account-info read `reload()`
-                    // used to set the hint. Trusting the stale claim here
-                    // would redirect to verifyEmailPath, which independently
-                    // resolves the user as verified via `getAuthUser()` and
-                    // redirects home — an infinite loop. Hint `true` wins.
+                    // A `true` hint means the client already observed
+                    // verification live; never redirect against it, even if
+                    // this mint's claim hasn't caught up.
                     unverifiedEmail = hint !== 'true' && decodeJwtPayload(token)?.email_verified === false;
                 }
                 else if (result.status === 'invalid') {
@@ -404,8 +416,7 @@ export default async function updateSession(request, baseResponse, locale, rebui
             }
         }
         else {
-            // Hint confirms unverified — no reason to refresh, trust the claim.
-            unverifiedEmail = true;
+            unverifiedEmail = hint !== 'true' && decodeJwtPayload(token)?.email_verified === false;
         }
     }
     if (refreshWasTransientFailure) {

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "cloudflare-next-intl",
-	"version": "0.8.27",
+	"version": "0.8.29",
 	"description": "Optimized Next Intl Package Special for App Router and Cloudflare",
 	"main": "dist/index.js",
 	"types": "dist/index.d.ts",