ultimate-jekyll-manager 1.3.5 → 1.3.7

package/CHANGELOG.md

@@ -14,6 +14,20 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 - `Fixed` for any bug fixes.
 - `Security` in case of vulnerabilities.
 
+---
+## [1.3.7] - 2026-05-24
+
+### Fixed
+
+- **Reverse-signup detection on `/signin` was completely broken.** The reverse-signup-on-/signin flow in `src/assets/js/libs/auth.js` (lines 289 and 664) was reading `result.additionalUserInfo?.isNewUser` directly off the `UserCredential` returned by `getRedirectResult()` and `signInWithPopup()`. That property does NOT exist on the v9+ modular SDK — verified against `@firebase/auth`'s `auth-public.d.ts`, which declares `UserCredential` as exactly `{ user, providerId, operationType }`. The legacy compat SDK exposed `additionalUserInfo` as a direct property, hence the v9 migration footgun. On the modular SDK you must call the standalone helper `getAdditionalUserInfo(userCredential): AdditionalUserInfo | null` to access `isNewUser`. Result: `isNewUser` was always `undefined` → always falsy → the `if (isNewUser && !isSignupPage)` reverse gate at line 296 never fired in production. New Google accounts on `/signin` got signed in straight to `/account` with no consent on record, despite the reverse-signup code existing in the bundle since multiple versions ago. Confirmed live on Somiibo (Test 4 of `TODO-CONSENT-LIVETEST.md` failed 3× in a row with `operationType: 'signIn'` and no `[Auth] Reversing accidental signup` log line). Now both sites import `getAdditionalUserInfo` and call it on the result. Added two `console.warn` diagnostic logs (one per site) so future regressions surface immediately — can be removed once we're confident the fix sticks.
+
+---
+## [1.3.6] - 2026-05-24
+
+### Fixed
+
+- **`auth/error-code:-47` now shows a friendly message instead of the raw FirebaseError.** v1.3.5's diagnostic confirmed: on the OAuth redirect path (`signInWithIdp` → 503), Firebase strips the BEM-side `HttpsError` message and delivers `code: 'auth/error-code:-47'` with `customData: {}` — empty. There's nothing to extract because Firebase ate the message client-side. This contradicts Firebase's own [Identity Platform docs](https://cloud.google.com/identity-platform/docs/blocking-functions) which describe a `BLOCKING_FUNCTION_ERROR_RESPONSE` wrapper that SHOULD carry the original message. The wrapper works on the 400 path (email signup, OAuth popup) — our v1.3.4 extractor handles that fine. The 503 path is broken: tracked at [firebase-js-sdk#8054](https://github.com/firebase/firebase-js-sdk/issues/8054), where a Firebase engineer said "503 seems to be the working as design error codes" then the issue was auto-closed as stale 5 weeks later without a fix or workaround. The `-47` code is 1:1 with "blocking-function rejected this signup," so `extractBlockingFunctionMessage()` now returns a generic-but-helpful message covering all three BEM `beforeCreate` reasons (rate limit, disposable email, custom hook reject): "Account creation is temporarily restricted. This can happen if you've recently created too many accounts, or your email is on our blocked list. Please try again later or contact support." The original `customData.serverResponse` path stays as the primary handler — the `-47` catchall is an additive fallback for when Firebase eats the message.
+
 ---
 ## [1.3.5] - 2026-05-24
 

package/dist/assets/js/libs/auth.js

@@ -266,7 +266,7 @@ export default function () {
   async function handleRedirectResult() {
     try {
       // Import Firebase auth functions
-      const { getAuth, getRedirectResult } = await import('@firebase/auth');
+      const { getAuth, getRedirectResult, getAdditionalUserInfo } = await import('@firebase/auth');
       const auth = getAuth();
 
       // Check for redirect result
@@ -285,10 +285,17 @@ export default function () {
       // Determine the provider from the result
       const providerId = result.providerId || result.user.providerData?.[0]?.providerId || 'unknown';
 
-      // Track based on whether this is a new user
-      const isNewUser = result.additionalUserInfo?.isNewUser;
+      // Track based on whether this is a new user. Firebase Auth v9+ modular SDK
+      // does NOT expose additionalUserInfo as a direct property on UserCredential —
+      // you must call getAdditionalUserInfo(result) to get it. The legacy compat SDK
+      // exposed it as a direct property, hence the v9 migration footgun. Verified
+      // against @firebase/auth's auth-public.d.ts: UserCredential only declares
+      // { user, providerId, operationType }.
+      const additionalUserInfo = getAdditionalUserInfo(result);
+      const isNewUser = additionalUserInfo?.isNewUser;
       const pagePath = document.documentElement.getAttribute('data-page-path');
       const isSignupPage = pagePath === '/signup';
+      console.warn('[Auth] redirect additionalUserInfo:', additionalUserInfo, 'isNewUser:', isNewUser, 'pagePath:', pagePath, 'isSignupPage:', isSignupPage, 'operationType:', result.operationType);
 
       // Google quirk: if a new account was auto-created during a signin attempt
       // (user came back from OAuth via the redirect path on /signin, not /signup),
@@ -598,6 +605,7 @@ export default function () {
         getAuth,
         signInWithPopup,
         signInWithRedirect,
+        getAdditionalUserInfo,
         GoogleAuthProvider,
         FacebookAuthProvider,
         TwitterAuthProvider,
@@ -660,8 +668,12 @@ export default function () {
           const result = await signInWithPopup(auth, provider);
           console.log('[Auth] Successfully authenticated via popup:', result.user.email);
 
-          // Track based on whether this is a new user
-          const isNewUser = result.additionalUserInfo?.isNewUser;
+          // Track based on whether this is a new user. v9 modular SDK requires
+          // getAdditionalUserInfo(result) — the legacy `result.additionalUserInfo`
+          // direct property does NOT exist on UserCredential in v9+.
+          const additionalUserInfoPopup = getAdditionalUserInfo(result);
+          const isNewUser = additionalUserInfoPopup?.isNewUser;
+          console.warn('[Auth] popup additionalUserInfo:', additionalUserInfoPopup, 'isNewUser:', isNewUser, 'action:', action);
 
           // Google quirk: signInWithPopup auto-creates accounts. If a brand-new visitor
           // clicks "Sign in with Google" on the SIGNIN page (not signup), reverse the
@@ -816,6 +828,16 @@ export default function () {
       fullError: error,
     });
 
+    // The OAuth redirect path (signInWithIdp → 503) delivers the rejection as
+    // `auth/error-code:-47` with NO `customData.serverResponse` blob — Firebase
+    // strips the BEM-side message before it reaches the client. The code is
+    // 1:1 with "blocking-function rejected this signup," so surface a generic-
+    // but-helpful message that covers all three BEM beforeCreate reasons
+    // (rate limit, disposable email, custom hook reject).
+    if (error?.code === 'auth/error-code:-47') {
+      return 'Account creation is temporarily restricted. This can happen if you\'ve recently created too many accounts, or your email is on our blocked list. Please try again later or contact support.';
+    }
+
     const raw = error?.customData?.serverResponse;
     if (!raw) {
       return null;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ultimate-jekyll-manager",
-  "version": "1.3.5",
+  "version": "1.3.7",
   "description": "Ultimate Jekyll dependency manager",
   "main": "dist/index.js",
   "exports": {