Merged
Conversation
…isPublicPath logic to handle RegExp patterns - Maintained backward compatibility with string patterns - Closes #345
Contributor
## Walkthrough
This update introduces a new PortalLink component and portal route, adds a request queue manager for serialized token processing in the setup handler, expands support for RegExp in publicPaths, and enhances prefetch handling in multiple handlers. It also corrects type definitions, centralizes cookie option logic, updates the changelog, and removes the ESLint config.
## Changes
| File(s) / Group | Change Summary |
|--------------------------------------------------------------------|---------------|
| CHANGELOG.md | Extended changelog with detailed entries for versions 2.6.0–2.8.2, including new features, bug fixes, and release dates. |
| src/components/PortalLink.tsx, src/components/index.js | Added new PortalLink React component and exported it. |
| src/config/index.ts, src/handlers/auth.js, src/handlers/portal.ts | Added portal route to config and handlers; implemented new portal handler. |
| src/handlers/callback.ts | Added early handling for login_link_expired errors with reauth state parsing and redirect logic. |
| src/handlers/createOrg.ts, src/handlers/login.ts, src/handlers/logout.ts, src/handlers/register.ts | Improved prefetch detection and response; updated function signature for createOrg. |
| src/handlers/setup.ts, src/utils/workQueue.ts | Refactored setup handler to use new RequestQueueManager class for serialized execution and granular error handling. |
| src/authMiddleware/authMiddleware.ts | Enhanced publicPaths to support RegExp, centralized error/redirect logic, improved debug logging, and used standardized cookie options. |
| src/utils/cookies/getSplitSerializedCookies.ts, src/utils/cookies/getStandardCookieOptions.ts | Centralized and standardized cookie option logic via new utility function. |
| src/types.ts | Corrected property names in KindeOrganizationProperties type. |
| src/utils/validateState.ts | Expanded allowed characters in validateState regex. |
| src/utils/version.js | Updated exported version constant to '2.8.2'. |
| eslint.config.mjs | Removed ESLint configuration file. |
## Sequence Diagram(s)
```mermaid
sequenceDiagram
participant Client
participant Middleware
participant Handler
participant RequestQueueManager
participant KindeClient
Client->>Middleware: Request to protected route
Middleware->>Middleware: Check publicPaths (string/RegExp)
Middleware->>Handler: Forward request if not public
Handler->>RequestQueueManager: Enqueue setup task
RequestQueueManager->>Handler: Execute setup logic
Handler->>KindeClient: Validate tokens / Refresh if expired
KindeClient-->>Handler: Return tokens or error
Handler->>RequestQueueManager: Resolve/reject task
Handler-->>Client: Respond with user/session info or errorsequenceDiagram
participant Client
participant PortalLink
participant PortalHandler
participant KindeClient
Client->>PortalLink: Clicks portal link
PortalLink->>PortalHandler: Navigates to /portal route
PortalHandler->>KindeClient: Retrieve access token from session
alt No token
PortalHandler-->>Client: Redirect to login
else Token exists
PortalHandler->>KindeClient: Generate portal URL
KindeClient-->>PortalHandler: Return portal URL
PortalHandler-->>Client: Redirect to portal URL
end
Possibly related PRs
Suggested reviewers
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (5)
src/utils/workQueue.ts (1)
33-50: Consider production-ready improvements for queue processing.The queue processing logic is sound, but consider these enhancements:
- Debug logging: The
console.debugcalls should be conditionally enabled based on debug mode configuration- Queue size limits: Consider adding a maximum queue size to prevent unbounded growth
- Stack overflow prevention: While unlikely, the recursive
processQueue()call could theoretically cause issues with very large queuesFor the debug logging, you could wrap the calls:
- console.debug("enqueue: task added to queue"); + if (config.isDebugMode) console.debug("enqueue: task added to queue");- console.debug("processQueue: task executed successfully"); + if (config.isDebugMode) console.debug("processQueue: task executed successfully");- console.debug("processQueue: task execution failed", error); + if (config.isDebugMode) console.debug("processQueue: task execution failed", error);src/handlers/register.ts (1)
19-22: LGTM! Consider documenting the supports_reauth parameter.The addition of
supports_reauth: "true"parameter and spreading of existing search params looks correct for supporting reauthentication flows. Consider adding a comment to document what this parameter enables.src/components/PortalLink.tsx (1)
32-38: Consider removing unnecessary null check.The null check for
portalUrlappears unnecessary since the URL construction will always produce a truthy string given thatconfig.apiPathandroutes.portalare expected to be defined.- return ( - portalUrl && ( - <a href={portalUrl} {...props}> - {children} - </a> - ) - ); + return ( + <a href={portalUrl} {...props}> + {children} + </a> + );src/handlers/portal.ts (1)
23-49: Consider memory storage cleanup and error handling improvements.The memory storage instance created here doesn't appear to be cleaned up after use, which could lead to memory leaks if the storage holds references. Additionally, the error logging on line 46 might expose sensitive information.
Consider these improvements:
const storage = new MemoryStorage(); setActiveStorage(storage); const accessToken = await routerClient.sessionManager.getSessionItem("access_token"); if (!accessToken) { return routerClient.redirect(`${config.apiPath}/${routes.login}`); } await storage.setSessionItem(StorageKeys.accessToken, accessToken); const returnUrl = routerClient.searchParams.get("returnUrl") || config.redirectURL; try { const generateResult = await generatePortalUrl({ subNav: routerClient.searchParams.get("subNav") as PortalPage, returnUrl, domain: config.issuerURL, }); if (generateResult.url) { return routerClient.redirect(generateResult.url.toString()); } } catch (error) { - console.error("Portal URL generation failed:", error); + console.error("Portal URL generation failed"); + if (config.isDebugMode) { + console.error("Error details:", error); + } return routerClient.redirect(config.redirectURL); +} finally { + // Clean up storage if needed + setActiveStorage(null); }src/handlers/setup.ts (1)
19-21: Good implementation of request queuing, consider adding timeout handling.The use of
RequestQueueManagersingleton effectively serializes concurrent setup requests, preventing race conditions. This is a solid solution for the token validation flow.Consider implementing timeout handling for queued requests to prevent indefinite waiting under high load. You might want to add a configurable timeout option to the queue manager.
Also applies to: 155-155
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
.release-it.jsonis excluded by!**/*.jsonpackage.jsonis excluded by!**/*.jsonpnpm-lock.yamlis excluded by!**/pnpm-lock.yaml,!**/*.yaml
📒 Files selected for processing (20)
CHANGELOG.md(1 hunks)eslint.config.mjs(0 hunks)src/authMiddleware/authMiddleware.ts(6 hunks)src/components/PortalLink.tsx(1 hunks)src/components/index.js(1 hunks)src/config/index.ts(2 hunks)src/handlers/auth.js(2 hunks)src/handlers/callback.ts(1 hunks)src/handlers/createOrg.ts(1 hunks)src/handlers/login.ts(2 hunks)src/handlers/logout.ts(1 hunks)src/handlers/portal.ts(1 hunks)src/handlers/register.ts(1 hunks)src/handlers/setup.ts(1 hunks)src/types.ts(1 hunks)src/utils/cookies/getSplitSerializedCookies.ts(1 hunks)src/utils/cookies/getStandardCookieOptions.ts(1 hunks)src/utils/validateState.ts(1 hunks)src/utils/version.js(1 hunks)src/utils/workQueue.ts(1 hunks)
💤 Files with no reviewable changes (1)
- eslint.config.mjs
🧰 Additional context used
🧠 Learnings (13)
📓 Common learnings
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#229
File: src/session/sessionManager.js:165-188
Timestamp: 2024-11-13T10:45:31.961Z
Learning: There's a new implementation coming soon for `src/session/sessionManager.js`, so refactoring suggestions related to cookie parsing logic may not be necessary at this time.
Learnt from: Yoshify
PR: kinde-oss/kinde-auth-nextjs#254
File: src/session/isAuthenticated.js:14-17
Timestamp: 2024-12-17T00:41:07.608Z
Learning: In `src/session/isAuthenticated.js` of this Next.js application, cookies cannot be modified in React Server Components (RSC). Therefore, to prevent accessing stale data outside of middleware, the application redirects on token expiry.
src/handlers/auth.js (1)
Learnt from: Yoshify
PR: kinde-oss/kinde-auth-nextjs#254
File: src/session/isAuthenticated.js:14-17
Timestamp: 2024-12-17T00:41:07.608Z
Learning: In `src/session/isAuthenticated.js` of this Next.js application, cookies cannot be modified in React Server Components (RSC). Therefore, to prevent accessing stale data outside of middleware, the application redirects on token expiry.
src/handlers/logout.ts (3)
Learnt from: Yoshify
PR: kinde-oss/kinde-auth-nextjs#254
File: src/session/isAuthenticated.js:14-17
Timestamp: 2024-12-17T00:41:07.608Z
Learning: In `src/session/isAuthenticated.js` of this Next.js application, cookies cannot be modified in React Server Components (RSC). Therefore, to prevent accessing stale data outside of middleware, the application redirects on token expiry.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#264
File: src/frontend/AuthProvider.jsx:54-54
Timestamp: 2025-01-31T17:11:40.324Z
Learning: In the Kinde Auth NextJS SDK, route validation and default fallbacks for undefined routes are handled in the config/index.ts file through the validateRoute function, making additional route validation unnecessary in components.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#318
File: src/session/getFlag.js:23-23
Timestamp: 2025-03-28T12:12:55.741Z
Learning: The sessionManager function in the Kinde Auth NextJS package returns a Promise that must be properly awaited before using its result, especially when passing it to functions like kindeClient.getClaimValue().
src/config/index.ts (2)
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#264
File: src/frontend/AuthProvider.jsx:54-54
Timestamp: 2025-01-31T17:11:40.324Z
Learning: In the Kinde Auth NextJS SDK, route validation and default fallbacks for undefined routes are handled in the config/index.ts file through the validateRoute function, making additional route validation unnecessary in components.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#243
File: src/session/getIdToken.js:21-22
Timestamp: 2024-11-21T17:55:06.897Z
Learning: In the Kinde Auth Next.js library, the `getIdToken(req, res)` function in `src/utils/getIdToken.ts` performs token validation using `validateToken` from `@kinde/jwt-validator`, ensuring proper token validation before decoding.
src/handlers/register.ts (3)
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#243
File: src/authMiddleware/authMiddleware.ts:46-49
Timestamp: 2024-11-21T09:58:35.193Z
Learning: In `src/authMiddleware/authMiddleware.ts`, the `validateToken` function from `@kinde/jwt-validator` handles exceptions internally, so additional error handling is not necessary when calling it.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#264
File: src/frontend/AuthProvider.jsx:54-54
Timestamp: 2025-01-31T17:11:40.324Z
Learning: In the Kinde Auth NextJS SDK, route validation and default fallbacks for undefined routes are handled in the config/index.ts file through the validateRoute function, making additional route validation unnecessary in components.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#318
File: src/session/getFlag.js:23-23
Timestamp: 2025-03-28T12:12:55.741Z
Learning: The sessionManager function in the Kinde Auth NextJS package returns a Promise that must be properly awaited before using its result, especially when passing it to functions like kindeClient.getClaimValue().
src/handlers/login.ts (5)
Learnt from: Yoshify
PR: kinde-oss/kinde-auth-nextjs#254
File: src/session/isAuthenticated.js:14-17
Timestamp: 2024-12-17T00:41:07.608Z
Learning: In `src/session/isAuthenticated.js` of this Next.js application, cookies cannot be modified in React Server Components (RSC). Therefore, to prevent accessing stale data outside of middleware, the application redirects on token expiry.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#247
File: src/utils/refreshTokens.ts:1-28
Timestamp: 2024-11-21T23:20:11.083Z
Learning: In `src/utils/refreshTokens.ts` and related files, logging is only enabled when debug mode is active and is not intended for production use.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#264
File: src/frontend/AuthProvider.jsx:54-54
Timestamp: 2025-01-31T17:11:40.324Z
Learning: In the Kinde Auth NextJS SDK, route validation and default fallbacks for undefined routes are handled in the config/index.ts file through the validateRoute function, making additional route validation unnecessary in components.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#318
File: src/session/getFlag.js:23-23
Timestamp: 2025-03-28T12:12:55.741Z
Learning: The sessionManager function in the Kinde Auth NextJS package returns a Promise that must be properly awaited before using its result, especially when passing it to functions like kindeClient.getClaimValue().
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#243
File: src/session/getIdToken.js:21-22
Timestamp: 2024-11-21T17:55:06.897Z
Learning: In the Kinde Auth Next.js library, the `getIdToken(req, res)` function in `src/utils/getIdToken.ts` performs token validation using `validateToken` from `@kinde/jwt-validator`, ensuring proper token validation before decoding.
src/utils/cookies/getStandardCookieOptions.ts (1)
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#229
File: src/session/sessionManager.js:165-188
Timestamp: 2024-11-13T10:45:31.961Z
Learning: There's a new implementation coming soon for `src/session/sessionManager.js`, so refactoring suggestions related to cookie parsing logic may not be necessary at this time.
src/authMiddleware/authMiddleware.ts (8)
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#243
File: src/authMiddleware/authMiddleware.ts:46-49
Timestamp: 2024-11-21T09:58:35.193Z
Learning: In `src/authMiddleware/authMiddleware.ts`, the `validateToken` function from `@kinde/jwt-validator` handles exceptions internally, so additional error handling is not necessary when calling it.
Learnt from: Yoshify
PR: kinde-oss/kinde-auth-nextjs#254
File: src/session/isAuthenticated.js:14-17
Timestamp: 2024-12-17T00:41:07.608Z
Learning: In `src/session/isAuthenticated.js` of this Next.js application, cookies cannot be modified in React Server Components (RSC). Therefore, to prevent accessing stale data outside of middleware, the application redirects on token expiry.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#229
File: src/session/sessionManager.js:165-188
Timestamp: 2024-11-13T10:45:31.961Z
Learning: There's a new implementation coming soon for `src/session/sessionManager.js`, so refactoring suggestions related to cookie parsing logic may not be necessary at this time.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#247
File: src/utils/refreshTokens.ts:1-28
Timestamp: 2024-11-21T23:20:11.083Z
Learning: In `src/utils/refreshTokens.ts` and related files, logging is only enabled when debug mode is active and is not intended for production use.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#243
File: src/authMiddleware/authMiddleware.ts:44-46
Timestamp: 2024-11-26T14:39:59.746Z
Learning: In the codebase, the `validateToken` function in `src/utils/validateToken.ts` internally uses `config.issuerURL` for the domain parameter. Therefore, when calling `validateToken`, we don't need to pass the `domain` parameter explicitly.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#243
File: src/session/getIdToken.js:21-22
Timestamp: 2024-11-21T17:55:06.897Z
Learning: In the Kinde Auth Next.js library, the `getIdToken(req, res)` function in `src/utils/getIdToken.ts` performs token validation using `validateToken` from `@kinde/jwt-validator`, ensuring proper token validation before decoding.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#318
File: src/session/getFlag.js:23-23
Timestamp: 2025-03-28T12:12:55.741Z
Learning: The sessionManager function in the Kinde Auth NextJS package returns a Promise that must be properly awaited before using its result, especially when passing it to functions like kindeClient.getClaimValue().
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#264
File: src/frontend/AuthProvider.jsx:54-54
Timestamp: 2025-01-31T17:11:40.324Z
Learning: In the Kinde Auth NextJS SDK, route validation and default fallbacks for undefined routes are handled in the config/index.ts file through the validateRoute function, making additional route validation unnecessary in components.
src/handlers/callback.ts (4)
Learnt from: Yoshify
PR: kinde-oss/kinde-auth-nextjs#254
File: src/session/isAuthenticated.js:14-17
Timestamp: 2024-12-17T00:41:07.608Z
Learning: In `src/session/isAuthenticated.js` of this Next.js application, cookies cannot be modified in React Server Components (RSC). Therefore, to prevent accessing stale data outside of middleware, the application redirects on token expiry.
Learnt from: Yoshify
PR: kinde-oss/kinde-auth-nextjs#254
File: src/session/isAuthenticated.js:15-19
Timestamp: 2024-12-18T12:34:59.343Z
Learning: In Next.js, calling the built-in redirect() function internally throws an error. If we wrap that call in a try/catch, we inadvertently catch the error and block the intended redirection flow.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#243
File: src/authMiddleware/authMiddleware.ts:46-49
Timestamp: 2024-11-21T09:58:35.193Z
Learning: In `src/authMiddleware/authMiddleware.ts`, the `validateToken` function from `@kinde/jwt-validator` handles exceptions internally, so additional error handling is not necessary when calling it.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#264
File: src/frontend/AuthProvider.jsx:54-54
Timestamp: 2025-01-31T17:11:40.324Z
Learning: In the Kinde Auth NextJS SDK, route validation and default fallbacks for undefined routes are handled in the config/index.ts file through the validateRoute function, making additional route validation unnecessary in components.
src/utils/cookies/getSplitSerializedCookies.ts (2)
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#229
File: src/session/sessionManager.js:165-188
Timestamp: 2024-11-13T10:45:31.961Z
Learning: There's a new implementation coming soon for `src/session/sessionManager.js`, so refactoring suggestions related to cookie parsing logic may not be necessary at this time.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#243
File: src/session/sessionManager.js:103-110
Timestamp: 2024-11-20T13:44:44.324Z
Learning: In `src/session/sessionManager.js`, the keys used in cookie management are prefixed and unique, so using `startsWith` to match cookie keys is acceptable.
CHANGELOG.md (5)
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#264
File: src/frontend/AuthProvider.jsx:54-54
Timestamp: 2025-01-31T17:11:40.324Z
Learning: In the Kinde Auth NextJS SDK, route validation and default fallbacks for undefined routes are handled in the config/index.ts file through the validateRoute function, making additional route validation unnecessary in components.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#243
File: src/session/getIdToken.js:21-22
Timestamp: 2024-11-21T17:55:06.897Z
Learning: In the Kinde Auth Next.js library, the `getIdToken(req, res)` function in `src/utils/getIdToken.ts` performs token validation using `validateToken` from `@kinde/jwt-validator`, ensuring proper token validation before decoding.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#318
File: src/session/getFlag.js:23-23
Timestamp: 2025-03-28T12:12:55.741Z
Learning: The sessionManager function in the Kinde Auth NextJS package returns a Promise that must be properly awaited before using its result, especially when passing it to functions like kindeClient.getClaimValue().
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#243
File: src/authMiddleware/authMiddleware.ts:46-49
Timestamp: 2024-11-21T09:58:35.193Z
Learning: In `src/authMiddleware/authMiddleware.ts`, the `validateToken` function from `@kinde/jwt-validator` handles exceptions internally, so additional error handling is not necessary when calling it.
Learnt from: Yoshify
PR: kinde-oss/kinde-auth-nextjs#254
File: src/session/isAuthenticated.js:14-17
Timestamp: 2024-12-17T00:41:07.608Z
Learning: In `src/session/isAuthenticated.js` of this Next.js application, cookies cannot be modified in React Server Components (RSC). Therefore, to prevent accessing stale data outside of middleware, the application redirects on token expiry.
src/handlers/portal.ts (3)
Learnt from: Yoshify
PR: kinde-oss/kinde-auth-nextjs#254
File: src/session/isAuthenticated.js:14-17
Timestamp: 2024-12-17T00:41:07.608Z
Learning: In `src/session/isAuthenticated.js` of this Next.js application, cookies cannot be modified in React Server Components (RSC). Therefore, to prevent accessing stale data outside of middleware, the application redirects on token expiry.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#229
File: src/session/sessionManager.js:165-188
Timestamp: 2024-11-13T10:45:31.961Z
Learning: There's a new implementation coming soon for `src/session/sessionManager.js`, so refactoring suggestions related to cookie parsing logic may not be necessary at this time.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#264
File: src/frontend/AuthProvider.jsx:54-54
Timestamp: 2025-01-31T17:11:40.324Z
Learning: In the Kinde Auth NextJS SDK, route validation and default fallbacks for undefined routes are handled in the config/index.ts file through the validateRoute function, making additional route validation unnecessary in components.
src/handlers/setup.ts (6)
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#243
File: src/authMiddleware/authMiddleware.ts:46-49
Timestamp: 2024-11-21T09:58:35.193Z
Learning: In `src/authMiddleware/authMiddleware.ts`, the `validateToken` function from `@kinde/jwt-validator` handles exceptions internally, so additional error handling is not necessary when calling it.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#243
File: src/session/getIdToken.js:21-22
Timestamp: 2024-11-21T17:55:06.897Z
Learning: In the Kinde Auth Next.js library, the `getIdToken(req, res)` function in `src/utils/getIdToken.ts` performs token validation using `validateToken` from `@kinde/jwt-validator`, ensuring proper token validation before decoding.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#318
File: src/session/getFlag.js:23-23
Timestamp: 2025-03-28T12:12:55.741Z
Learning: The sessionManager function in the Kinde Auth NextJS package returns a Promise that must be properly awaited before using its result, especially when passing it to functions like kindeClient.getClaimValue().
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#247
File: src/utils/refreshTokens.ts:1-28
Timestamp: 2024-11-21T23:20:11.083Z
Learning: In `src/utils/refreshTokens.ts` and related files, logging is only enabled when debug mode is active and is not intended for production use.
Learnt from: Yoshify
PR: kinde-oss/kinde-auth-nextjs#254
File: src/session/isAuthenticated.js:14-17
Timestamp: 2024-12-17T00:41:07.608Z
Learning: In `src/session/isAuthenticated.js` of this Next.js application, cookies cannot be modified in React Server Components (RSC). Therefore, to prevent accessing stale data outside of middleware, the application redirects on token expiry.
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#264
File: src/frontend/AuthProvider.jsx:54-54
Timestamp: 2025-01-31T17:11:40.324Z
Learning: In the Kinde Auth NextJS SDK, route validation and default fallbacks for undefined routes are handled in the config/index.ts file through the validateRoute function, making additional route validation unnecessary in components.
🧬 Code Graph Analysis (4)
src/handlers/auth.js (2)
src/config/index.ts (1)
routes(145-162)src/handlers/portal.ts (1)
portal(17-49)
src/components/PortalLink.tsx (1)
src/config/index.ts (2)
config(102-139)routes(145-162)
src/utils/cookies/getStandardCookieOptions.ts (1)
src/utils/constants.ts (2)
TWENTY_NINE_DAYS(3-3)GLOBAL_COOKIE_OPTIONS(5-10)
src/utils/cookies/getSplitSerializedCookies.ts (3)
src/utils/splitString.ts (1)
splitString(1-6)src/utils/constants.ts (1)
MAX_COOKIE_LENGTH(23-23)src/utils/cookies/getStandardCookieOptions.ts (1)
getStandardCookieOptions(5-14)
🔇 Additional comments (22)
src/types.ts (1)
205-207: LGTM! Typo fixes for organization property names.The corrections properly fix the misspelled property names:
kp_org_industr→kp_org_industrykp_org_tate_region→kp_org_state_regionThese fixes ensure consistency with the expected organization data structure.
src/config/index.ts (2)
152-152: LGTM! Portal route type definition added.The addition of the
portalroute to the type definition is consistent with the existing route structure.
161-161: LGTM! Portal route configuration follows established pattern.The portal route configuration properly uses the existing
validateRoutefunction for input validation and provides an appropriate fallback value, maintaining consistency with other route configurations.src/utils/cookies/getStandardCookieOptions.ts (1)
1-14: LGTM! Well-designed cookie options utility.The implementation effectively centralizes cookie option configuration with:
- Proper TypeScript typing using
Omit<ResponseCookie, "name" | "value">- Conditional domain setting based on configuration
- Good use of constants and spread operator for option merging
- Clear separation of concerns for reusability
This promotes consistency across the codebase for cookie handling.
src/utils/workQueue.ts (2)
7-19: LGTM! Singleton pattern correctly implemented.The singleton implementation properly ensures a single instance across the application, which is important for managing a global request queue.
21-31: LGTM! Well-structured enqueue method with proper typing.The generic type support and promise-based approach provide good type safety and usability. The queue item structure correctly captures the task execution and resolution logic.
src/utils/version.js (1)
2-2: LGTM! Version bump aligns with release objectives.The version update to 2.8.2 properly reflects the maintenance release being merged from the 2.x branch to main.
src/handlers/auth.js (1)
8-8: LGTM! Portal handler integration follows established patterns.The portal handler import and route mapping are consistent with the existing codebase structure and properly integrate the new portal functionality into the authentication routing system.
Also applies to: 24-24
src/components/index.js (1)
4-4: LGTM! PortalLink export follows established pattern.The export addition is consistent with the existing component exports and properly exposes the new PortalLink component for external use.
src/handlers/logout.ts (1)
13-13: LGTM! Prefetch handling standardization improves consistency.The change from returning
nullto an explicit JSON response with "Prefetch skipped" message provides better visibility into prefetch request handling and aligns with standardization across other handlers.src/handlers/register.ts (1)
13-13: LGTM! Consistent prefetch handling.The prefetch handling change aligns with the standardization across other authentication handlers.
src/handlers/login.ts (2)
13-13: LGTM! Consistent prefetch handling.The prefetch handling change maintains consistency with other authentication handlers.
29-32: LGTM! Consistent reauthentication support.The addition of
supports_reauth: "true"parameter and spreading of existing search params matches the implementation in the register handler, ensuring consistent reauthentication support across both authentication flows.src/utils/validateState.ts (1)
2-2: LGTM! Enhanced regex pattern for base64 support.The addition of
+,/, and=characters to the validation pattern appropriately supports base64-encoded state values, which are commonly used in OAuth flows.src/utils/cookies/getSplitSerializedCookies.ts (2)
1-3: LGTM! Good refactoring to centralize cookie options.The simplification of imports and delegation to
getStandardCookieOptions()improves maintainability by centralizing cookie configuration logic.
10-10: Clean implementation using centralized cookie options.The replacement of inline cookie options with the utility function call maintains the same functionality while improving code organization.
src/handlers/createOrg.ts (2)
1-4: LGTM! Proper imports for prefetch handling.The addition of necessary imports for prefetch detection aligns with the consistent pattern used across other handlers.
10-14: Excellent performance optimization with prefetch detection.The early return for prefetch requests prevents unnecessary processing and follows the consistent pattern established across handlers. The explicit typing for
routerClientparameter also improves type safety.src/components/PortalLink.tsx (2)
5-9: Well-designed TypeScript interface.The interface properly extends React anchor attributes and includes the necessary portal-specific props with appropriate typing.
17-30: Clean URL construction with proper parameter handling.The URLSearchParams usage correctly handles optional query parameters, and the URL construction properly combines the configured API path and portal route.
src/handlers/callback.ts (1)
1-1: LGTM! Proper imports for enhanced error handling.The import of config and routes supports the new reauth state handling logic.
CHANGELOG.md (1)
7-57: LGTM!The changelog entries are well-formatted and document the version history appropriately.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (2)
src/utils/isPublicPathMatch.ts (1)
1-32: Fix Prettier formatting issues.The pipeline indicates Prettier formatting check failed. Please run
prettier --writeto fix code style issues.src/utils/isPublicPathMatch.test.ts (1)
1-54: Fix Prettier formatting issues.The pipeline indicates Prettier formatting check failed. Please run
prettier --writeto fix code style issues.
🧹 Nitpick comments (4)
src/utils/isValidEnumValue.test.ts (1)
25-28: Consider moving enum definition to top levelThe
NumberEnumdefinition inside the describe block is functionally correct but consider moving it to the top level alongsideTestEnumfor better organization and consistency.+enum NumberEnum { + ONE = 1, + TWO = 2, +} + describe("isValidEnumValue", () => { // ... existing tests ... - enum NumberEnum { - ONE = 1, - TWO = 2, - }src/utils/isPublicPathMatch.ts (1)
9-15: Consider simplifying RegExp handling logic.The monkey-patch detection logic for RegExp.test seems overly complex for this use case. The primary concern about RegExp mutation (global/sticky flags) is already handled by creating a new RegExp instance.
Consider simplifying this to:
- // If test is monkey-patched, use as-is (for test cases) - if (p.test !== RegExp.prototype.test) { - return p.test(pathname); - } - // Otherwise, create a new RegExp instance to avoid mutating the original - const regexCopy = new RegExp(p.source, p.flags); - return regexCopy.test(pathname); + // Create a new RegExp instance to avoid mutating the original + const regexCopy = new RegExp(p.source, p.flags); + return regexCopy.test(pathname);This maintains the same functionality while being more straightforward.
src/utils/isPublicPathMatch.test.ts (2)
41-46: Improve console.error mocking approach.The current approach directly manipulates the global console.error which could affect other tests. Consider using a more robust mocking approach.
- const origError = console.error; - let errorLogged = false; - console.error = () => { errorLogged = true; }; - expect(isPublicPathMatch("/foo", [badRe], debugTrue)).toBe(false); - expect(errorLogged).toBe(true); - console.error = origError; + const consoleSpy = vi.spyOn(console, 'error').mockImplementation(() => {}); + expect(isPublicPathMatch("/foo", [badRe], debugTrue)).toBe(false); + expect(consoleSpy).toHaveBeenCalled(); + consoleSpy.mockRestore();
51-51: Improve test safety for invalid input handling.The current approach uses unsafe type casting which could mask potential issues. Consider using a more explicit approach.
- expect(isPublicPathMatch("/foo", [null as unknown as string], debugFalse)).toBe(false); + expect(isPublicPathMatch("/foo", [undefined as any], debugFalse)).toBe(false);Or better yet, test with a more realistic invalid input scenario.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
src/authMiddleware/authMiddleware.ts(6 hunks)src/handlers/portal.ts(1 hunks)src/utils/isPublicPathMatch.test.ts(1 hunks)src/utils/isPublicPathMatch.ts(1 hunks)src/utils/isValidEnumValue.test.ts(1 hunks)src/utils/isValidEnumValue.ts(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- src/utils/isValidEnumValue.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- src/authMiddleware/authMiddleware.ts
- src/handlers/portal.ts
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: DanielRivers
PR: kinde-oss/kinde-auth-nextjs#229
File: src/session/sessionManager.js:165-188
Timestamp: 2024-11-13T10:45:31.961Z
Learning: There's a new implementation coming soon for `src/session/sessionManager.js`, so refactoring suggestions related to cookie parsing logic may not be necessary at this time.
Learnt from: Yoshify
PR: kinde-oss/kinde-auth-nextjs#254
File: src/session/isAuthenticated.js:14-17
Timestamp: 2024-12-17T00:41:07.608Z
Learning: In `src/session/isAuthenticated.js` of this Next.js application, cookies cannot be modified in React Server Components (RSC). Therefore, to prevent accessing stale data outside of middleware, the application redirects on token expiry.
🧬 Code Graph Analysis (2)
src/utils/isPublicPathMatch.test.ts (1)
src/utils/isPublicPathMatch.ts (1)
isPublicPathMatch(5-31)
src/utils/isValidEnumValue.test.ts (1)
src/utils/isValidEnumValue.ts (1)
isValidEnumValue(8-10)
🪛 GitHub Actions: Build and test
src/utils/isPublicPathMatch.test.ts
[warning] 1-1: Prettier formatting check failed. Run 'prettier --write' to fix code style issues.
src/utils/isPublicPathMatch.ts
[warning] 1-1: Prettier formatting check failed. Run 'prettier --write' to fix code style issues.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Analyze (javascript)
🔇 Additional comments (8)
src/utils/isValidEnumValue.test.ts (6)
1-2: LGTM: Clean imports and test setupThe imports are properly structured and the Vitest testing framework is correctly imported.
4-8: LGTM: Well-defined test enumThe
TestEnumprovides good test data with distinct string values for comprehensive testing.
10-15: LGTM: Comprehensive positive test casesThe test correctly validates all enum values and verifies the function returns
truefor valid inputs.
17-23: LGTM: Excellent negative test coverageThe test cases cover important edge cases including case sensitivity, empty strings, and null/undefined values. This ensures robust validation behavior.
30-33: LGTM: Proper numeric enum testingThe test correctly validates numeric enum values and demonstrates the function works with different enum types.
35-38: LGTM: Important type coercion testThe test correctly verifies that string "1" is not considered equal to numeric 1, which is crucial for type safety.
src/utils/isPublicPathMatch.ts (1)
5-31: Well-implemented utility function with good error handling.The implementation correctly handles:
- Mixed string and RegExp patterns
- Special root path matching for exact matches
- RegExp state preservation through cloning
- Graceful error handling with optional debug logging
The logic is sound and the function will work reliably in the authentication middleware.
src/utils/isPublicPathMatch.test.ts (1)
5-53: Excellent test coverage for the utility function.The test suite comprehensively covers:
- String pattern matching with prefix behavior
- Root path exact matching
- RegExp pattern matching
- RegExp with stateful flags (global/sticky)
- Mixed pattern types
- Error handling scenarios
- Debug logging functionality
This ensures the
isPublicPathMatchfunction will work reliably across various authentication middleware scenarios.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Explain your changes
bring 2.x branch into main
Checklist
🛟 If you need help, consider asking for advice over in the Kinde community.