feat: implement buildAuthUrl helper for consistent authorizationEndpoint handling

[p-stam001]

Summary

Implements a reusable buildAuthUrl helper function to provide consistent custom authorization endpoint support across both login and register functions.

Problem

The authorizationEndpoint prop was only implemented in the login function with inline logic, while the register function completely ignored this prop, causing inconsistent behavior.

Solution

Created a centralized buildAuthUrl helper function that:

• ✅ Handles custom authorization endpoint URL construction
• ✅ Ensures pathname normalization (adds leading / if missing)
• ✅ Preserves original query parameters and domain
• ✅ Falls back to original URL when no custom endpoint is provided

Implementation Details

const buildAuthUrl = useCallback((authUrl: { url: URL }): string => {
  if (!authorizationEndpoint) {
    return authUrl.url.toString();
  }

  const customUrl = new URL(authUrl.url.toString());
  // Ensure it's a path, not a full URL
  customUrl.pathname = authorizationEndpoint.startsWith("/")
    ? authorizationEndpoint
    : `/${authorizationEndpoint}`;
  
  return customUrl.toString();
}, [authorizationEndpoint]);

[coderabbitai]

Walkthrough

Added optional authorizationEndpoint parameter to KindeProviderProps with a new buildAuthUrl helper function that rewrites authentication URLs. Updated login and register flows to use this helper when computing final authorization URLs. Loosened redirect URI checks with optional chaining for safer window location access.

Changes

Cohort / File(s)	Summary
Authentication endpoint configuration src/state/KindeProvider.tsx	Added optional authorizationEndpoint?: string prop to KindeProviderProps and integrated it into authentication flows via new buildAuthUrl helper function for URL rewriting
Login and register flow updates src/state/KindeProvider.tsx	Modified login and register handlers to compute finalAuthUrl using buildAuthUrl helper and pass it to navigation instead of raw authUrl
Error handling improvements src/state/KindeProvider.tsx	Loosened redirect URI validation with optional chaining for window.location.href to prevent undefined errors in isOnRedirectUri checks

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~15 minutes

Possibly related PRs

• kinde-oss/kinde-auth-react#157: Modifies KindeProvider.tsx authentication navigation and provider props similarly.
• kinde-oss/kinde-auth-react#135: Updates login/register flows in the same file with different authentication handling enhancements.

Suggested reviewers

• evgenyk
• DaveOrDead

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The pull request title "feat: implement buildAuthUrl helper for consistent authorizationEndpoint handling" directly and fully captures the main change in the changeset. The title accurately reflects the primary objective of introducing a new buildAuthUrl helper function to provide consistent custom authorization endpoint support across both login and register functions. The title is concise, specific, and would allow a teammate scanning the commit history to immediately understand the core purpose of this change without vague or misleading language.
Description Check	✅ Passed	The pull request description is clearly related to the changeset and provides meaningful information about the changes. It explains the problem (inconsistent authorizationEndpoint handling between login and register), the solution (centralized buildAuthUrl helper), and includes concrete implementation details with code examples. The description is well-structured with dedicated sections for Summary, Problem, Solution, and Implementation Details, making it easy to understand both the "what" and "why" of the changes.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ 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/state/KindeProvider.tsx (1)

197-212: Consider adding input validation for authorizationEndpoint.

The implementation correctly preserves the domain and query parameters by only modifying the pathname. However, consider validating that authorizationEndpoint is a reasonable path value (e.g., doesn't contain unexpected characters, protocols, or path traversal sequences like ..). While setting URL.pathname should sanitize most issues, defensive validation would make the intent clearer and prevent potential misuse.

Additionally, consider adding JSDoc to document the expected format of authorizationEndpoint (e.g., "should be a path like /oauth/authorize").

Example validation:

 const buildAuthUrl = useCallback((authUrl: { url: URL }): string => {
   if (!authorizationEndpoint) {
     return authUrl.url.toString();
   }
+  
+  // Validate that authorizationEndpoint is a simple path
+  if (authorizationEndpoint.includes('://') || authorizationEndpoint.includes('?')) {
+    console.warn('authorizationEndpoint should be a path, not a full URL or query string');
+  }

   const customUrl = new URL(authUrl.url.toString());

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3b8cad1 and ea610a1.

📒 Files selected for processing (1)

• src/state/KindeProvider.tsx (8 hunks)

🔇 Additional comments (5)

src/state/KindeProvider.tsx (5)

97-97: LGTM: Clean addition of the optional prop.

The authorizationEndpoint prop is correctly typed and integrated into the component signature.

Also applies to: 143-143

---

243-243: LGTM: Correct integration of buildAuthUrl in login flow.

The helper is properly invoked and the result is used consistently. The dependency array correctly includes buildAuthUrl.

Also applies to: 247-247, 262-262

---

294-299: LGTM: Consistent implementation in register flow.

The register function now correctly applies the same buildAuthUrl logic as login, addressing the inconsistency mentioned in the PR objectives. The dependency array is properly updated.

Also applies to: 325-325

---

631-631: Clarify the necessity of optional chaining here.

In a browser environment, window.location.href should always be defined. Is this change addressing a TypeScript strict mode requirement, or is there a specific scenario (e.g., SSR, test environment) where window.location.href could be undefined? While the defensive programming doesn't cause issues, it seems unrelated to the main feature and might indicate an underlying concern worth documenting.

---

197-212: Implementation verified as correct and consistent.

The buildAuthUrl helper correctly:

• Preserves domain and query parameters by using new URL() constructor
• Handles custom authorizationEndpoint by modifying only the pathname
• Normalizes leading slashes in the endpoint path
• Is used consistently in both login (line 243) and register (line 294-296) flows
• Has proper dependency tracking in the useCallback dependency array