fix: auto-detect port in auth client baseURL

[jezweb]

Problem

The auth client hardcodes localhost:3000, which breaks when:

• Port 3000 is already in use (Next.js auto-assigns 3001, 3002, etc.)
• Running multiple dev instances simultaneously
• Testing on different ports

Solution

Use window.location.origin to auto-detect the current URL in the browser. This works for:

• Any localhost port (3000, 3001, 8080, etc.)
• Production deployments
• Custom domains

Falls back to NEXT_PUBLIC_AUTH_URL env var for SSR compatibility.

Testing

• ✅ Tested with Next.js on port 3001 (when 3000 was in use)
• ✅ Google OAuth login works correctly
• ✅ No hardcoded ports needed

Changes

• Modified src/modules/auth/utils/auth-client.ts
• Changed from hardcoded port to dynamic detection

Summary by CodeRabbit

• Bug Fixes
  • Improved authentication URL detection to properly handle both browser and server environments, ensuring correct URL resolution in all runtime contexts.

[coderabbitai]

Walkthrough

The auth client's baseURL determination logic was refactored to use browser detection instead of NODE_ENV checks. When in a browser, it uses window.location.origin; in non-browser environments, it defaults to NEXT_PUBLIC_AUTH_URL or http://localhost:3000.

Changes

Cohort / File(s)	Change Summary
Auth Client Configuration src/modules/auth/utils/auth-client.ts	Replaced NODE_ENV-based baseURL logic with browser-first approach; in-browser uses window.location.origin, server-side defaults to environment variable or localhost

Sequence Diagram(s)

sequenceDiagram
    participant Client as Client Code
    participant AuthClient as authClient
    participant BrowserCheck as Environment Check
    participant URLResolution as URL Resolution

    Client->>AuthClient: Initialize
    AuthClient->>BrowserCheck: Running in browser?
    alt Browser Environment
        BrowserCheck->>URLResolution: Use window.location.origin
        URLResolution-->>AuthClient: baseURL set to browser origin
    else Server Environment
        BrowserCheck->>URLResolution: Check NEXT_PUBLIC_AUTH_URL
        alt Env Var Set
            URLResolution-->>AuthClient: baseURL set to env var
        else Env Var Not Set
            URLResolution-->>AuthClient: baseURL set to http://localhost:3000
        end
    end
    AuthClient-->>Client: Ready with baseURL

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• Single focused file change with straightforward logic replacement
• Control flow simplification (two-branch check vs. multi-condition logic)
• No breaking changes to exported signatures
• Verify NEXT_PUBLIC_AUTH_URL handling in different deployment environments

Poem

🐰 With browser magic now supreme,
Our auth client takes the gleam—
window.origin when near,
Env vars when far, crystal clear!
Localhost stands as fallback friend,
On these new paths, we now depend! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix: auto-detect port in auth client baseURL' clearly and specifically describes the main change: replacing hardcoded port logic with dynamic port detection in the auth client baseURL configuration.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

src/modules/auth/utils/auth-client.ts (1)

9-9: Consider validating the NEXT_PUBLIC_AUTH_URL format.

The fallback to process.env.NEXT_PUBLIC_AUTH_URL should ideally validate that it's a properly formatted URL. An invalid format could lead to runtime errors that are difficult to debug.

 export const authClient = createAuthClient({
     baseURL:
         typeof window !== "undefined"
             ? window.location.origin // Auto-detect from browser URL (works for any port)
-            : process.env.NEXT_PUBLIC_AUTH_URL || "http://localhost:3000", // Fallback for SSR
+            : process.env.NEXT_PUBLIC_AUTH_URL || "http://localhost:3000", // Fallback for SSR
 });

Alternatively, add validation logic:

const getBaseURL = () => {
    if (typeof window !== "undefined") {
        return window.location.origin;
    }
    
    const envURL = process.env.NEXT_PUBLIC_AUTH_URL;
    if (envURL && !envURL.startsWith("http")) {
        console.warn("NEXT_PUBLIC_AUTH_URL should start with http:// or https://");
    }
    return envURL || "http://localhost:3000";
};

export const authClient = createAuthClient({
    baseURL: getBaseURL(),
});

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a44687a and 386e6f3.

📒 Files selected for processing (1)

• src/modules/auth/utils/auth-client.ts (1 hunks)

🔇 Additional comments (1)

src/modules/auth/utils/auth-client.ts (1)

7-9: Architecture verified: auth backend is correctly implemented as Next.js API routes.

The verification confirms the auth backend is deployed at src/app/api/auth/[...all]/route.ts as part of the same Next.js application. The window.location.origin auto-detection is the correct approach for this same-origin architecture, and the process.env.NEXT_PUBLIC_AUTH_URL fallback provides appropriate SSR handling. No security concerns for this deployment model.

[jezweb]

Not sure if this is actually a bug or just I didn't use it properly but Claude fixed it so that I could get it working.