Google OAuth Signup Broken on Qoruz

Summary

Google OAuth signup on Qoruz is completely non-functional. The OAuth flow completes successfully on Google's side (consent granted, popup closes), but Qoruz's frontend sends the resulting JWT to /api/register without the required gReCaptchaToken field. The backend returns a 422 Unprocessable Entity, the frontend silently swallows the error, and the user sees no feedback whatsoever. The page simply stays on the signup form as if nothing happened.

This is not a client-side or browser-specific issue. It is a server-side validation misconfiguration combined with a frontend error-handling gap.

Test Environment

The bug was reproduced across every reasonable combination of browser mode, Google account type, OAuth method, and session timing. The failure is deterministic and account-agnostic.

Steps to Reproduce

On subsequent visits, Google's FedCM surfaces a "Sign in as [Name]" pill at the bottom of the form (confirming prior OAuth authorization was stored). Clicking this triggers the same flow with the same silent failure, except the "Sign Up" button briefly shows a spinner before reverting.

OAuth Flow: Where It Breaks

Root Cause Analysis

Primary Cause: Missing reCAPTCHA Token in Google OAuth Payload

The POST /api/register request sent by the frontend after Google OAuth completion contains the following payload:

{
  "oauthResponse": "<Google JWT>",
  "is_google_login": true,
  "utm_source": "SEO",
  "utm_medium": "organic search",
  "lead_source": "Inbound - SEO",
  "lead_page": "signup"
}

The backend returns:

{
  "ok": false,
  "error": "validation_failed",
  "validation_errors": {
    "gReCaptchaToken": [
      "The g re captcha token field is required."
    ]
  },
  "stuff": "The given data was invalid."
}

The backend requires gReCaptchaToken as a mandatory field on every /api/register call. The manual signup form includes a reCAPTCHA widget that generates and attaches this token. The Google OAuth signup path bypasses the reCAPTCHA widget entirely and never includes the token in its payload. The backend does not differentiate between OAuth and manual signups in its validation rules.

Secondary Cause: Silent Error Handling on Frontend

When the /api/register call returns a 422, the frontend does not surface any error to the user. No modal, no toast, no inline error message, no console-visible user-facing error. The user is left staring at an unchanged signup form with no indication that something went wrong. The only evidence is in the browser's Network tab (the failed register request) and Console (a POST 422 error line buried under hundreds of carousel warnings).

Contributing Issue: COOP Header Blocking postMessage

The browser console logs the following during the OAuth callback:

Cross-Origin-Opener-Policy policy would block the window.postMessage call.

This indicates that the Cross-Origin-Opener-Policy headers on app.qoruz.com are interfering with the communication channel between the Google OAuth popup and the parent page. While the OAuth token does eventually reach the parent page (evidenced by the /api/register call being made), this COOP misconfiguration could cause intermittent failures or race conditions in the popup-to-parent handoff.

Contributing Issue: Duplicate GSI Initialization

[GSI_LOGGER]: google.accounts.id.initialize() is called multiple times.

Google's Sign-In library is being initialized more than once, likely triggered by the testimonial carousel's continuous re-rendering (the carousel fires setState in an infinite loop due to a missing showThumbs={false} prop). This could cause unpredictable behavior in the OAuth callback registration.

Evidence: Verified Across Multiple Attempts

Request / Response Timing

The timing profile is consistent across all attempts, confirming the server processes and rejects the request deterministically:

The server responds in under 170ms with the 422, meaning it hits the validation layer immediately and never reaches account creation logic.

Additional Observations

Work Email Enforcement Gap

Even if the reCAPTCHA issue were fixed, Google OAuth signup using public email domains (Gmail, Yahoo, etc.) would hit a second wall. Qoruz requires a "work email" for registration. The manual form surfaces a clear modal for this restriction. The Google OAuth path has no equivalent handling. It would receive the Gmail address from the JWT, attempt to register, and presumably fail at the email domain validation stage (which currently never fires because the reCAPTCHA validation fails first).

Carousel Rendering Loop

The testimonial carousel on the signup page fires renderThumbs errors in an infinite loop. Each cycle triggers a setState call, causing continuous re-renders. The console accumulates hundreds of warnings within seconds. The fix: set showThumbs={false} on the Carousel component.

Mixed Content Warnings

The page loads an asset over HTTP from an HTTPS page (http://terareach.s3.ap-southeast-1.amazonaws.com/...). Chrome auto-upgrades this, but it indicates the S3 bucket references haven't been updated to use HTTPS URLs.

Recommended Fixes

Decoded JWT Payloads

Both JWTs are correctly signed, contain valid expiry timestamps, and match Qoruz's registered OAuth client ID. The issue is entirely on Qoruz's side.

Attempt with knewsiq@gmail.com

Attempt with kulki@knewsiq.com