feat: adds api for password authentication via auth0#2333
Conversation
WalkthroughAdds password-based auth endpoints and a SessionService that exchanges tokens with an OAuth provider, provisions/enriches local users, integrates Auth0 session seeding (setSession), renames OAuth signup to loginViaOauth across UI and tests, tunes notification retry attempts, and updates build/test config for Changes
Sequence Diagram(s)sequenceDiagram
actor User
participant Browser as Client
participant API as /api/auth/password-login
participant SessionSvc as SessionService
participant Auth0 as OAuth Provider
participant ConsoleAPI as Console API (/v1/)
participant SDK as `@auth0/nextjs-auth0` (SessionCache)
User->>Browser: submits email & password
Browser->>API: POST /api/auth/password-login {email,password}
API->>SessionSvc: signIn({email,password})
rect rgba(200,220,255,0.35)
SessionSvc->>Auth0: POST /oauth/token (password realm)
Auth0-->>SessionSvc: { id_token, access_token, refresh_token }
SessionSvc->>Auth0: GET /userinfo
Auth0-->>SessionSvc: user profile
end
rect rgba(200,255,220,0.35)
SessionSvc->>ConsoleAPI: POST /v1/register-user (with access token)
ConsoleAPI-->>SessionSvc: UserSettings
SessionSvc->>ConsoleAPI: GET /v1/user/me (enrichment)
ConsoleAPI-->>SessionSvc: Local user details
end
rect rgba(255,235,205,0.35)
SessionSvc-->>API: merged Session (incl. local settings)
API->>SDK: setSession(req,res,session)
SDK-->>API: persisted session/cache
end
API-->>Browser: 204 No Content
Browser-->>User: login success
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
stalniy
force-pushed
the
feat/embeded-login-api
branch
from
55510c5 to
9631375
Compare
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| startingDelay: 500, | ||
| timeMultiple: 2, | ||
| numOfAttempts: 10 | ||
| numOfAttempts: 5 |
There was a problem hiding this comment.
reduced it because in case of failure, login request can stuck for about 30+ seconds
stalniy
force-pushed
the
feat/embeded-login-api
branch
from
9631375 to
241978d
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
apps/api/src/notifications/services/notification/notification.service.ts (1)
6-11: Addressas anycasts that violate coding guidelinesThe existing
as anycasts on lines 26 and 48 violate the project's coding guidelines ("Never use typeanyor cast to typeany"). These should be replaced with proper TypeScript types instead of casting the parameters object.Regarding
numOfAttempts: 5: this affects bothcreateNotificationandcreateDefaultChannelcall sites. Since both are external API calls and 5 retries is reasonable for these operations, the change is acceptable.apps/deploy-web/src/pages/api/auth/[...auth0].ts (1)
31-37:isGeneralAxiosErrorshould checkerror.response?.statusinstead oferror.statusIn axios v1.x, the HTTP status code is reliably exposed via
error.response?.status, noterror.status. The current implementation at line 116–118 checks the latter, which is less reliable.Update it to:
function isGeneralAxiosError(error: unknown): error is AxiosError { return isAxiosError(error) && error.response?.status !== undefined && error.response.status >= 400 && error.response.status < 500; }This ensures client errors (400–499) are correctly identified and logged with warning severity, while other errors fall through to the 503 path.
🧹 Nitpick comments (9)
apps/api/src/notifications/services/notification/notification.service.ts (1)
23-27: Avoidas anyon request parameters; use concrete types insteadThe
as anycasts on theparameters.headerobjects effectively disable type checking for these requests and conflict with the “noany” guideline. It would be better to expose proper parameter types fromnotifications-api.provider(forcreateNotificationandcreateDefaultChannel) or to introduce narrow local types for the headers and use those here, instead of relying onany.Also applies to: 45-49
apps/deploy-web/src/pages/api/auth/password-login.ts (1)
1-27: Password-login API handler looks correct; consider minor ergonomics tweaksThe flow (schema validation →
sessionService.signIn→setSessionon success, 400 with error body on failure) is consistent and sound.Two small optional improvements:
- Use the validated
bodyfrom the handler context instead ofreq.bodyto fully leverage the zod schema.- If desired, tighten
passwordvalidation (e.g.z.string().min(1)) to reject obviously invalid payloads earlier; Auth0 will still enforce its own rules downstream.apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx (1)
14-37: Mutation-based signup wiring is solid; consider guarding link clicks when pendingThe switch to a
useMutationthat callsauthService.loginViaOauth()is clean and removes custom loading state nicely. Button wiring withdisabled={signup.isPending}also looks good.For the
"link"wrapper, you currently setaria-disabled={signup.isPending}but still passonClick={signup.mutate}, so repeated clicks while the mutation is pending will still trigger additional calls. Consider wrapping the handler to short‑circuit when pending, e.g.:const handleClick: React.MouseEventHandler = event => { if (signup.isPending) { event.preventDefault(); return; } signup.mutate(event); };and use
handleClickfor both Button and Link.apps/deploy-web/src/pages/api/auth/password-signup.ts (1)
42-45: Avoid sending a body with a 204 response
res.status(204).json(null);technically violates the 204 “No Content” semantics. It usually works in practice but can confuse some clients or tooling.Consider either returning 200 with a body or ending the 204 without one:
- await setSession(req, res, result.val); - res.status(204).json(null); + await setSession(req, res, result.val); + res.status(204).end();apps/deploy-web/src/services/auth/auth/auth.service.ts (1)
32-45: Password-based login/signup API wrappers are straightforward
loginandsignupcorrectly target/api/auth/password-loginand/api/auth/password-signupwith the expected payloads, keeping the AuthService surface simple and typed.If you anticipate reusing these input shapes elsewhere, you might later extract them into named interfaces for consistency, but it’s not required right now.
apps/deploy-web/src/services/session/session.service.ts (1)
20-31: Consider resilience when local user APIs failBoth
signInandsignUpassume that/v1/user/meand/v1/register-usersucceed; any network/4xx-5xx issues will cause the entire auth flow to fail even when Auth0 credentials are valid.Depending on your requirements, you might want to:
- Treat local user API failures as non-fatal (log + return a session without enriched
userSettings), or- Map them into a distinct error code (e.g.,
local_user_error) so the UI can differentiate credential issues from local user provisioning issues.This can be done by wrapping the
getLocalUserDetails/createLocalUsercalls in try/catch and returning either a downgraded session or a structured Err.Also applies to: 122-135
apps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts (1)
1-22: Refactor test to use a setup() helper per repo test guidelinesThe test is functionally fine, but it doesn’t follow the project’s convention of using a
setuphelper at the bottom of the rootdescribeblock.You can refactor like this:
process.env.AUTH0_SECRET ??= "test-secret"; process.env.AUTH0_CLIENT_ID ??= "test-client-id"; process.env.AUTH0_CLIENT_SECRET ??= "test-client-secret"; import { getSession, Session } from "@auth0/nextjs-auth0"; import { mock } from "jest-mock-extended"; import type { NextApiRequest, NextApiResponse } from "next"; import { setSession } from "./setSession"; describe(setSession.name, () => { - it("can set session", async () => { - const req = mock<NextApiRequest>(); - const res = mock<NextApiResponse>(); - const session = new Session({ - someClaim: "someValue" - }); - await setSession(req, res, session); - - expect(await getSession(req, res)).toEqual(session); - }); + it("can set session", async () => { + const { req, res, session } = setup({}); + + await setSession(req, res, session); + + expect(await getSession(req, res)).toEqual(session); + }); + + function setup({}: { }): { + req: NextApiRequest; + res: NextApiResponse; + session: Session; + } { + const req = mock<NextApiRequest>(); + const res = mock<NextApiResponse>(); + const session = new Session({ + someClaim: "someValue" + }); + + return { req, res, session }; + } });This keeps behavior the same while matching the repo’s testing pattern.
apps/deploy-web/src/pages/api/auth/signup.ts (1)
41-42: Guardreq.query.connectionbefore passing it throughThe new
connectionparameter is useful, butreq.query.connectioncan bestring | string[]. The cast won’t affect runtime, so an array could still leak through.Consider narrowing explicitly:
- authorizationParams: { + const connectionParam = + typeof req.query.connection === "string" ? req.query.connection : undefined; + + authorizationParams: { // Note that this can be combined with prompt=login , which indicates if @@ - action: "signup", // <== Classic Universal Login - connection: req.query.connection as string | undefined + action: "signup", // <== Classic Universal Login + connection: connectionParam }This keeps the handler robust even if
connectionis provided multiple times.apps/deploy-web/src/services/auth/auth/auth.service.spec.ts (1)
15-33: Tests now exercise loginViaOauth correctly; consider renaming the suiteSwitching the calls from
signuptologinViaOauthkeeps the expectations and behavior intact and matches the new AuthService API.For clarity, you might also rename the nested suite:
-describe("signup", () => { +describe("loginViaOauth", () => {so the description matches the method under test.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (20)
apps/api/src/notifications/services/notification/notification.service.ts(1 hunks)apps/deploy-web/jest.config.ts(3 hunks)apps/deploy-web/next.config.js(3 hunks)apps/deploy-web/package.json(1 hunks)apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx(1 hunks)apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx(2 hunks)apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsx(1 hunks)apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsx(1 hunks)apps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts(1 hunks)apps/deploy-web/src/lib/auth0/setSession/setSession.ts(1 hunks)apps/deploy-web/src/pages/api/auth/[...auth0].ts(4 hunks)apps/deploy-web/src/pages/api/auth/password-login.ts(1 hunks)apps/deploy-web/src/pages/api/auth/password-signup.ts(1 hunks)apps/deploy-web/src/pages/api/auth/signup.ts(1 hunks)apps/deploy-web/src/services/app-di-container/server-di-container.service.ts(2 hunks)apps/deploy-web/src/services/auth/auth/auth.service.spec.ts(2 hunks)apps/deploy-web/src/services/auth/auth/auth.service.ts(2 hunks)apps/deploy-web/src/services/session/session.service.ts(1 hunks)apps/deploy-web/src/utils/encoding.ts(1 hunks)packages/ui/styles/global.css(1 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (.cursor/rules/general.mdc)
**/*.{ts,tsx,js}: Never use typeanyor cast to typeany. Always define the proper TypeScript types.
Never use deprecated methods from libraries.
Don't add unnecessary comments to the code.
Files:
apps/deploy-web/src/lib/auth0/setSession/setSession.spec.tsapps/deploy-web/src/utils/encoding.tsapps/deploy-web/src/services/auth/auth/auth.service.spec.tsapps/deploy-web/src/pages/api/auth/password-login.tsapps/deploy-web/src/lib/auth0/setSession/setSession.tsapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsxapps/api/src/notifications/services/notification/notification.service.tsapps/deploy-web/src/pages/api/auth/password-signup.tsapps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsxapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsxapps/deploy-web/jest.config.tsapps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsxapps/deploy-web/next.config.jsapps/deploy-web/src/pages/api/auth/[...auth0].tsapps/deploy-web/src/services/app-di-container/server-di-container.service.tsapps/deploy-web/src/pages/api/auth/signup.tsapps/deploy-web/src/services/auth/auth/auth.service.tsapps/deploy-web/src/services/session/session.service.ts
**/*.spec.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/no-jest-mock.mdc)
Don't use
jest.mock()in test files. Instead, usejest-mock-extendedto create mocks and pass mocks as dependencies to the service under testUse
setupfunction instead ofbeforeEachin test files. Thesetupfunction must be at the bottom of the rootdescribeblock, should create an object under test and return it, accept a single parameter with inline type definition, avoid shared state, and not have a specified return type.
**/*.spec.{ts,tsx}: Use<Subject>.namein the root describe suite description instead of hardcoded class/service name strings to enable automated refactoring tools to find all references
Use either a method name or a condition starting with 'when' for nested suite descriptions in tests
Use present simple, 3rd person singular for test descriptions without prepending 'should'
Files:
apps/deploy-web/src/lib/auth0/setSession/setSession.spec.tsapps/deploy-web/src/services/auth/auth/auth.service.spec.tsapps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsxapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx
{apps/deploy-web,apps/provider-console}/**/*.spec.tsx
📄 CodeRabbit inference engine (.cursor/rules/query-by-in-tests.mdc)
Use
queryBymethods instead ofgetBymethods in test expectations
Files:
apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsxapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx
🧠 Learnings (9)
📚 Learning: 2025-11-25T17:45:52.965Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/setup-instead-of-before-each.mdc:0-0
Timestamp: 2025-11-25T17:45:52.965Z
Learning: Applies to **/*.spec.{ts,tsx} : Use `setup` function instead of `beforeEach` in test files. The `setup` function must be at the bottom of the root `describe` block, should create an object under test and return it, accept a single parameter with inline type definition, avoid shared state, and not have a specified return type.
Applied to files:
apps/deploy-web/src/lib/auth0/setSession/setSession.spec.tsapps/deploy-web/src/services/auth/auth/auth.service.spec.tsapps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsxapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsxapps/deploy-web/jest.config.ts
📚 Learning: 2025-11-25T17:45:49.180Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/query-by-in-tests.mdc:0-0
Timestamp: 2025-11-25T17:45:49.180Z
Learning: Applies to {apps/deploy-web,apps/provider-console}/**/*.spec.tsx : Use `queryBy` methods instead of `getBy` methods in test expectations
Applied to files:
apps/deploy-web/src/services/auth/auth/auth.service.spec.tsapps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsxapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx
📚 Learning: 2025-11-25T17:45:44.790Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/no-jest-mock.mdc:0-0
Timestamp: 2025-11-25T17:45:44.790Z
Learning: Applies to **/*.spec.{ts,tsx} : Don't use `jest.mock()` in test files. Instead, use `jest-mock-extended` to create mocks and pass mocks as dependencies to the service under test
Applied to files:
apps/deploy-web/src/services/auth/auth/auth.service.spec.tsapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsxapps/deploy-web/jest.config.ts
📚 Learning: 2025-11-25T17:45:58.258Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/test-descriptions.mdc:0-0
Timestamp: 2025-11-25T17:45:58.258Z
Learning: Applies to **/*.spec.{ts,tsx} : Use `<Subject>.name` in the root describe suite description instead of hardcoded class/service name strings to enable automated refactoring tools to find all references
Applied to files:
apps/deploy-web/src/services/auth/auth/auth.service.spec.tsapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx
📚 Learning: 2025-09-10T08:40:53.104Z
Learnt from: stalniy
Repo: akash-network/console PR: 1892
File: apps/deploy-web/src/components/new-deployment/BidCountdownTimer.tsx:20-31
Timestamp: 2025-09-10T08:40:53.104Z
Learning: In TanStack Query v5, the onSuccess and onError callbacks were removed from useQuery options. Instead, use useEffect with the data as a dependency to handle side effects when query data changes.
Applied to files:
apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx
📚 Learning: 2025-07-11T10:46:43.711Z
Learnt from: stalniy
Repo: akash-network/console PR: 1660
File: apps/deploy-web/src/components/alerts/DeploymentAlertsContainer/DeploymentAlertsContainer.spec.tsx:54-56
Timestamp: 2025-07-11T10:46:43.711Z
Learning: In apps/{deploy-web,provider-console}/**/*.spec.tsx files: Use `getBy` methods instead of `queryBy` methods when testing element presence with `toBeInTheDocument()` because `getBy` throws an error and shows DOM state when element is not found, providing better debugging information than `queryBy` which returns null.
Applied to files:
apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsx
📚 Learning: 2025-11-25T17:45:58.258Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/test-descriptions.mdc:0-0
Timestamp: 2025-11-25T17:45:58.258Z
Learning: Applies to **/*.spec.{ts,tsx} : Use either a method name or a condition starting with 'when' for nested suite descriptions in tests
Applied to files:
apps/deploy-web/jest.config.ts
📚 Learning: 2025-11-12T16:36:02.543Z
Learnt from: baktun14
Repo: akash-network/console PR: 2203
File: apps/deploy-web/src/components/onboarding/steps/PaymentMethodContainer/PaymentMethodContainer.tsx:161-168
Timestamp: 2025-11-12T16:36:02.543Z
Learning: In apps/deploy-web/src/components/onboarding/steps/PaymentMethodContainer/PaymentMethodContainer.tsx, the organization field captured during payment method setup is internal metadata. Errors from stripe.updateCustomerOrganization should be logged to Sentry but not surfaced to users, and the flow should continue even if the organization update fails, as it's non-critical and not something users can fix.
Applied to files:
apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsx
📚 Learning: 2025-08-12T13:52:38.708Z
Learnt from: stalniy
Repo: akash-network/console PR: 1800
File: apps/deploy-web/next.config.js:163-165
Timestamp: 2025-08-12T13:52:38.708Z
Learning: In the Akash Console project, akashnetwork/env-loader is used at the top of next.config.js files to automatically load environment variables from env/.env files into process.env. SENTRY_ORG and SENTRY_PROJECT are stored as public configuration values in apps/deploy-web/env/.env and are loaded this way, while only SENTRY_AUTH_TOKEN is handled as a GitHub secret in workflows.
Applied to files:
apps/deploy-web/next.config.js
🧬 Code graph analysis (10)
apps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts (1)
apps/deploy-web/src/lib/auth0/setSession/setSession.ts (1)
setSession(47-59)
apps/deploy-web/src/pages/api/auth/password-login.ts (3)
apps/deploy-web/src/lib/nextjs/defineApiHandler/defineApiHandler.ts (1)
defineApiHandler(13-53)apps/deploy-web/src/services/app-di-container/server-di-container.service.ts (1)
services(24-50)apps/deploy-web/src/lib/auth0/setSession/setSession.ts (1)
setSession(47-59)
apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx (2)
apps/deploy-web/src/services/auth/auth/auth.service.ts (1)
signup(39-45)packages/ui/components/button.tsx (1)
Button(46-46)
apps/deploy-web/src/pages/api/auth/password-signup.ts (2)
apps/deploy-web/src/lib/nextjs/defineApiHandler/defineApiHandler.ts (1)
defineApiHandler(13-53)apps/deploy-web/src/lib/auth0/setSession/setSession.ts (1)
setSession(47-59)
apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx (1)
apps/deploy-web/src/services/auth/auth/auth.service.ts (2)
AuthService(7-52)signup(39-45)
apps/deploy-web/next.config.js (4)
packages/dev-config/.eslintrc.next.js (1)
path(1-1)packages/dev-config/.eslintrc.ts.js (1)
path(1-1).eslintrc.js (1)
path(1-1)apps/stats-web/next.config.js (2)
require(2-2)require(5-5)
apps/deploy-web/src/pages/api/auth/[...auth0].ts (1)
apps/deploy-web/src/services/app-di-container/server-di-container.service.ts (1)
services(24-50)
apps/deploy-web/src/services/app-di-container/server-di-container.service.ts (2)
apps/deploy-web/src/services/app-di-container/browser-di-container.ts (1)
services(24-59)apps/deploy-web/src/services/session/session.service.ts (1)
SessionService(9-169)
apps/deploy-web/src/services/auth/auth/auth.service.ts (1)
apps/deploy-web/src/services/session/session.service.ts (1)
input(33-90)
apps/deploy-web/src/services/session/session.service.ts (2)
apps/deploy-web/src/types/user.ts (1)
UserSettings(5-17)apps/deploy-web/src/utils/encoding.ts (1)
fromBase64Url(23-27)
⏰ 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). (7)
- GitHub Check: test-build
- GitHub Check: test-build
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: validate / validate-app
- GitHub Check: validate / validate-app
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (12)
apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsx (1)
68-84: Onboarding trial test correctly migrated tologinViaOauthThe expectation on Line 83 now targets
authService.loginViaOauthwith areturnTocontaining/onboarding, which aligns with the updated onboarding flow and AuthService API.apps/deploy-web/jest.config.ts (1)
2-67: Auth0 Jest wiring looks consistent; verify TS/Jest support forimport.meta.urlThe added
createRequire+pathusage and the moduleNameMapper/transform settings for@auth0/nextjs-auth0(including the dedicatedunit-nodeproject) align with thesetSessionhack and should let Jest resolve and transform Auth0 internals correctly.One thing to double-check in your environment is that
jest.config.tsis executed under a TS/Node configuration that supportsimport.meta.url(e.g. NodeNext/ESM mode or appropriate transpilation), otherwisecreateRequire(import.meta.url)could fail at startup.apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx (1)
48-79: Tests correctly rewire tologinViaOauthwhile preserving setup helper APIUpdating the setup helper to type
signupasAuthService["loginViaOauth"]and wiring the mock with{ loginViaOauth: signup }keeps existing tests intact while pointing them at the new AuthService method, which is exactly what we want here.apps/deploy-web/src/services/app-di-container/server-di-container.service.ts (1)
12-49: SessionService DI wiring and dynamic base URLs look correctThe new
sessionServiceregistration correctly passes the external HTTP client, a console API client scoped toNEXT_PUBLIC_MANAGED_WALLET_NETWORK_ID, and the Auth0 config values. UpdatingnotificationsApito derive its base URL fromApiUrlServicekeeps things network-aware and consistent with other server-side clients.apps/deploy-web/src/lib/auth0/setSession/setSession.ts (1)
1-59: Auth0 session hack is implemented coherently; guard it with tests against upstream changesThe interception of
updateSessionModule.defaultto captureSessionCache, followed byensureSessionCacheInitialized+sessionModule.setinsetSession, is internally consistent and matches the documented workaround for creating sessions from Auth0 API responses.Given the reliance on
@auth0/nextjs-auth0’s internal modules, the main risk here is library upgrades silently breaking the aliasing or thesessionModule.setcontract. The new node-only tests around this helper are important—keep them in place and consider revisiting this file whenever bumping the Auth0 SDK version.apps/deploy-web/src/pages/api/auth/password-signup.ts (1)
6-35: Password & T&C validation looks goodThe password complexity checks and explicit T&C acceptance are clear and match typical security requirements; using Unicode property regexes is a nice touch for internationalization.
apps/deploy-web/src/services/auth/auth/auth.service.ts (1)
15-30: loginViaOauth extension withconnectionlooks correctAppending
connectionviaURLSearchParamspreserves existing behavior and cleanly adds the new capability without altering the redirect flow.apps/deploy-web/package.json (1)
127-127: ts-results dependency addition looks consistentAdding
ts-resultsaligns with the Result-based session/service patterns described elsewhere in the PR. No manifest issues from this change alone.apps/deploy-web/src/utils/encoding.ts (1)
23-27: fromBase64Url implementation is correct and robustThe normalization and padding logic for Base64URL input is sound and safely delegates to the existing
fromBase64, covering typical URL-safe token formats.packages/ui/styles/global.css (1)
6-7: Light theme variables correctly shared between :root and .lightExtending the base variable block to
:root, .lightis a straightforward way to support class-based light theming without impacting the dark theme block.apps/deploy-web/next.config.js (1)
12-12: Auth0 transpilation and server-only aliasing look correct; tighten robustness a bitThe additions for:
transpilePackagesincluding@auth0/nextjs-auth0, and- server-only aliases for
@auth0/nextjs-auth0/sessionand@auth0/nextjs-auth0/update-sessionfit well with the new server-side
setSessionhelper and should behave correctly on the server.Two small follow-ups you might consider:
- Defensive resolve initialization
To guard against any future changes to the base webpack config shape:
webpack: (config, options) => { @@ - if (options.isServer) { + if (options.isServer) { + config.resolve = config.resolve || {}; + config.resolve.alias = config.resolve.alias || {}; // see ./src/lib/auth0/setSession/setSession.ts for more details config.resolve.alias["@auth0/nextjs-auth0/session"] = path.join( require.resolve("@auth0/nextjs-auth0"), "..", "session", "index.js" ); config.resolve.alias["@auth0/nextjs-auth0/update-session"] = path.join( require.resolve("@auth0/nextjs-auth0"), "..", "session", "update-session.js" ); }
- Fix JSDoc type for
optionsThe second parameter is not a
NextConfig; it’s the webpack options context. If you want types there, a looser JSDoc such as@param {{ isServer: boolean }} options(or omitting the type) would be more accurate.Also applies to: 24-28, 61-80
apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsx (1)
159-177: Onboarding start-trial now correctly delegates to loginViaOauthRouting unauthenticated users through
authService.loginViaOauth({ returnTo: ... })keeps the existing return URL behavior while aligning the onboarding flow with the new AuthService API.
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/deploy-web/src/pages/api/auth/signup.ts (1)
44-53: Avoidanyin error handling; narrow fromunknowninsteadThe
catch (error: any)violates the “noany” guideline and weakens type safety. You can type this asunknownand then narrow based on shape before accessingstatus/message:- } catch (error: any) { + } catch (error: unknown) { let severity: SeverityLevel = "error"; - if (error?.status && error.status >= 400 && error.status < 500) { + if (typeof error === "object" && error !== null && "status" in error) { + const status = (error as { status?: number }).status; + if (typeof status === "number" && status >= 400 && status < 500) { + severity = "warning"; + res.status(400).send({ message: (error as { message?: string }).message }); + } else { + res.status(503).send({ message: "An unexpected error occurred. Please try again later." }); + } + } else { + res.status(503).send({ message: "An unexpected error occurred. Please try again later." }); + } - severity = "warning"; - res.status(400).send({ message: error.message }); - } else { - res.status(503).send({ message: "An unexpected error occurred. Please try again later." }); - }Adjust the narrowing to match the concrete error type(s) that
handleLoginactually throws.What error types does `handleLogin` from `@auth0/nextjs-auth0` v3.5.0 throw (shape of status/message), and is there a recommended TypeScript type to use instead of `any` in a catch block?
♻️ Duplicate comments (3)
apps/deploy-web/src/pages/api/auth/password-signup.ts (1)
11-13: Fix route metadata to match the password signup endpointThe handler in
password-signup.tscallssessionService.signUp, butrouteis set to"/api/auth/password-login". This only affects logging/trace routing but will mislabel this endpoint in Sentry/observability.Recommend aligning the route string with the actual path:
-export default defineApiHandler({ - route: "/api/auth/password-login", +export default defineApiHandler({ + route: "/api/auth/password-signup",apps/deploy-web/src/services/session/session.service.ts (2)
108-120: Fixmesssagetypo so signup errors surface server messageIn the non‑
invalid_passworderror path you accesssignupResponse.data.messsage(three “s”), so you’ll usually ignore the server’smessagefield and fall back todescriptionor"Signup failed".Use the correct property name:
- return Err({ - message: signupResponse.data.messsage || signupResponse.data.description || "Signup failed", - code: "signup_failed" - }); + return Err({ + message: signupResponse.data.message || signupResponse.data.description || "Signup failed", + code: "signup_failed" + });
185-191: Harden manual ID token decoding (or prefer Auth0 helpers) to avoid runtime crashes
getClaimsFromTokenassumes a well‑formed JWT, base64url payload, and valid JSON. Ifid_tokenis missing, malformed, or has a bad payload,token.split(".").at(1)andJSON.parsecan throw and take down the request.At minimum, guard the structure and wrap decode/parse in try/catch:
-function getClaimsFromToken(token: string) { - const stringifiedClaims = decoder.decode(fromBase64Url(token.split(".").at(1) || "")); - const claims = JSON.parse(stringifiedClaims, (key, value) => { - if (IDENTITY_CLAIM_FILTER.has(key)) return undefined; - return value; - }); - return claims; -} +function getClaimsFromToken(token: string) { + const [, payload] = token.split("."); + if (!payload) { + throw new Error("Invalid ID token format: missing payload"); + } + + let stringifiedClaims: string; + try { + stringifiedClaims = decoder.decode(fromBase64Url(payload)); + } catch { + throw new Error("Invalid ID token payload encoding"); + } + + try { + return JSON.parse(stringifiedClaims, (key, value) => { + if (IDENTITY_CLAIM_FILTER.has(key)) return undefined; + return value; + }); + } catch { + throw new Error("Invalid ID token payload JSON"); + } +}Longer‑term, consider using Auth0’s server‑side session helpers or their JWT utilities instead of rolling your own decoder.
What is the recommended way in Auth0 / `@auth0/nextjs-auth0` to obtain ID token claims server-side without manually decoding the JWT string, and does Auth0 provide a helper that can replace `getClaimsFromToken`?
🧹 Nitpick comments (2)
apps/deploy-web/src/lib/auth0/setSession/setSession.ts (1)
31-45: Consider logging initialization failures for debugging.The empty catch block silences all errors during SDK initialization. While the comment explains this is intentional, logging these errors (at least in development) would aid debugging if the SessionCache capture fails.
} catch { // we only care about triggering the SDK initialization so the SessionCache instance is captured + // Errors are expected when no session exists, but logging can help debug unexpected failures }Alternatively, consider logging in development:
} catch (error) { if (process.env.NODE_ENV === 'development') { console.debug('Session initialization error (expected if no session):', error); } }apps/deploy-web/src/pages/api/auth/password-signup.ts (1)
14-40: Prefer using validatedbodyfrom handler context instead ofreq.bodyYou already validate
bodywith zod viadefineApiHandler, but the handler still reads fromreq.body. Using the validatedbodymakes types tighter and avoids accidentally drifting from the schema.For example:
- async handler({ res, req, services }) { - const result = await services.sessionService.signUp({ - email: req.body.email, - password: req.body.password - }); + async handler({ res, services, body }) { + const result = await services.sessionService.signUp({ + email: body.email, + password: body.password + });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (22)
apps/api/src/notifications/services/notification/notification.service.ts(1 hunks)apps/deploy-web/jest.config.ts(3 hunks)apps/deploy-web/next.config.js(3 hunks)apps/deploy-web/package.json(1 hunks)apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx(3 hunks)apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx(2 hunks)apps/deploy-web/src/components/layout/AccountMenu.tsx(1 hunks)apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsx(1 hunks)apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsx(1 hunks)apps/deploy-web/src/hooks/useLoginRequiredEventHandler.tsx(1 hunks)apps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts(1 hunks)apps/deploy-web/src/lib/auth0/setSession/setSession.ts(1 hunks)apps/deploy-web/src/pages/api/auth/[...auth0].ts(4 hunks)apps/deploy-web/src/pages/api/auth/password-login.ts(1 hunks)apps/deploy-web/src/pages/api/auth/password-signup.ts(1 hunks)apps/deploy-web/src/pages/api/auth/signup.ts(1 hunks)apps/deploy-web/src/services/app-di-container/server-di-container.service.ts(2 hunks)apps/deploy-web/src/services/auth/auth/auth.service.spec.ts(2 hunks)apps/deploy-web/src/services/auth/auth/auth.service.ts(2 hunks)apps/deploy-web/src/services/session/session.service.ts(1 hunks)apps/deploy-web/src/utils/encoding.ts(1 hunks)packages/ui/styles/global.css(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (10)
- apps/deploy-web/src/pages/api/auth/password-login.ts
- apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx
- apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsx
- apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsx
- apps/api/src/notifications/services/notification/notification.service.ts
- apps/deploy-web/src/pages/api/auth/[...auth0].ts
- apps/deploy-web/src/services/auth/auth/auth.service.spec.ts
- apps/deploy-web/package.json
- apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx
- apps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (.cursor/rules/general.mdc)
**/*.{ts,tsx,js}: Never use typeanyor cast to typeany. Always define the proper TypeScript types.
Never use deprecated methods from libraries.
Don't add unnecessary comments to the code.
Files:
apps/deploy-web/src/components/layout/AccountMenu.tsxapps/deploy-web/src/utils/encoding.tsapps/deploy-web/src/pages/api/auth/password-signup.tsapps/deploy-web/src/services/app-di-container/server-di-container.service.tsapps/deploy-web/src/services/session/session.service.tsapps/deploy-web/src/hooks/useLoginRequiredEventHandler.tsxapps/deploy-web/src/lib/auth0/setSession/setSession.tsapps/deploy-web/jest.config.tsapps/deploy-web/next.config.jsapps/deploy-web/src/services/auth/auth/auth.service.tsapps/deploy-web/src/pages/api/auth/signup.ts
🧠 Learnings (4)
📚 Learning: 2025-11-25T17:45:44.790Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/no-jest-mock.mdc:0-0
Timestamp: 2025-11-25T17:45:44.790Z
Learning: Applies to **/*.spec.{ts,tsx} : Don't use `jest.mock()` in test files. Instead, use `jest-mock-extended` to create mocks and pass mocks as dependencies to the service under test
Applied to files:
apps/deploy-web/jest.config.ts
📚 Learning: 2025-11-25T17:45:52.965Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/setup-instead-of-before-each.mdc:0-0
Timestamp: 2025-11-25T17:45:52.965Z
Learning: Applies to **/*.spec.{ts,tsx} : Use `setup` function instead of `beforeEach` in test files. The `setup` function must be at the bottom of the root `describe` block, should create an object under test and return it, accept a single parameter with inline type definition, avoid shared state, and not have a specified return type.
Applied to files:
apps/deploy-web/jest.config.ts
📚 Learning: 2025-11-25T17:45:58.258Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/test-descriptions.mdc:0-0
Timestamp: 2025-11-25T17:45:58.258Z
Learning: Applies to **/*.spec.{ts,tsx} : Use either a method name or a condition starting with 'when' for nested suite descriptions in tests
Applied to files:
apps/deploy-web/jest.config.ts
📚 Learning: 2025-08-12T13:52:38.708Z
Learnt from: stalniy
Repo: akash-network/console PR: 1800
File: apps/deploy-web/next.config.js:163-165
Timestamp: 2025-08-12T13:52:38.708Z
Learning: In the Akash Console project, akashnetwork/env-loader is used at the top of next.config.js files to automatically load environment variables from env/.env files into process.env. SENTRY_ORG and SENTRY_PROJECT are stored as public configuration values in apps/deploy-web/env/.env and are loaded this way, while only SENTRY_AUTH_TOKEN is handled as a GitHub secret in workflows.
Applied to files:
apps/deploy-web/next.config.js
🧬 Code graph analysis (4)
apps/deploy-web/src/pages/api/auth/password-signup.ts (3)
apps/deploy-web/src/lib/nextjs/defineApiHandler/defineApiHandler.ts (1)
defineApiHandler(13-53)apps/deploy-web/src/services/app-di-container/server-di-container.service.ts (1)
services(24-50)apps/deploy-web/src/lib/auth0/setSession/setSession.ts (1)
setSession(47-59)
apps/deploy-web/src/services/session/session.service.ts (2)
apps/deploy-web/src/types/user.ts (1)
UserSettings(5-17)apps/deploy-web/src/utils/encoding.ts (1)
fromBase64Url(23-27)
apps/deploy-web/jest.config.ts (1)
apps/deploy-web/next.config.js (4)
require(5-5)require(11-11)require(15-15)path(12-12)
apps/deploy-web/src/services/auth/auth/auth.service.ts (1)
apps/deploy-web/src/services/session/session.service.ts (1)
input(33-90)
⏰ 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). (9)
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: test-build
- GitHub Check: test-build
- GitHub Check: test-build
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: Validate local packages
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (14)
packages/ui/styles/global.css (1)
6-6: CSS syntax is correct, but PR scope is unclear.The selector grouping (
:root, .light) is valid CSS and will correctly apply the light theme custom properties to both contexts. However, this file appears disconnected from the PR title about "password authentication via auth0."Please clarify:
- Are there additional files in this PR containing Auth0 API implementation? This CSS file alone only provides theme styling infrastructure.
- How is the
.lightclass applied to elements at runtime? (e.g., JavaScript state management, class toggling logic, component props).- What is the relationship between the Auth0 embedded login feature and this theme change? Is the embedded login component expected to operate in light-only mode, or will it respect both light and dark themes?
Without seeing the broader implementation context, I can only confirm the CSS is syntactically correct and follows the existing pattern with the
.darkselector.apps/deploy-web/src/utils/encoding.ts (1)
23-27: LGTM! Clean URL-safe base64 decoder.The implementation correctly handles the URL-safe base64 alphabet conversion and padding requirements before delegating to the existing
fromBase64function.apps/deploy-web/next.config.js (1)
12-12: LGTM! Necessary setup for Auth0 internal module access.Adding the
pathmodule and including@auth0/nextjs-auth0intranspilePackagesenables webpack to process and alias Auth0's internal modules for the server-side session workaround.Also applies to: 24-24
apps/deploy-web/jest.config.ts (2)
2-2: LGTM! Proper Jest setup for Auth0 internal module testing.The configuration correctly mirrors the webpack aliasing from
next.config.jsby mapping Auth0's internal modules to their actual file paths in the test environment.Also applies to: 4-4, 10-10, 15-18
59-67: LGTM! Appropriate transform configuration for Auth0 modules.The
transformIgnorePatternsand custom transformer ensure that@auth0/nextjs-auth0modules are processed byts-jestwhile othernode_modulesare excluded, enabling proper testing of the session workaround.apps/deploy-web/src/lib/auth0/setSession/setSession.ts (3)
1-14: LGTM! Excellent documentation of the workaround.The comprehensive comments clearly explain the problem, the solution approach, and the relationship to the webpack and Jest configurations. This will help future maintainers understand the implementation.
24-29: LGTM! Clever patching approach to capture SessionCache.The module patching strategy successfully intercepts the internal
updateSessionFactoryto capture theSessionCacheinstance needed for session management. While fragile, it's well-documented and necessary given the SDK limitations.
47-59: Verify session persistence across requests.The
setSessionimplementation correctly delegates to the captured SessionCache. Ensure that sessions created via this workaround persist correctly across subsequent requests and work with Auth0's standard session retrieval.Test that:
- Sessions created by
setSessionare retrievable viagetSessionin subsequent requests- Session expiry and refresh token flows work correctly
- The session is properly encrypted and stored according to Auth0's security requirements
Based on the test file
apps/deploy-web/src/lib/auth0/setSession/setSession.spec.tsmentioned in the AI summary, these scenarios should already be covered, but verify in integration tests as well.apps/deploy-web/src/services/auth/auth/auth.service.ts (2)
15-30: LGTM! Clear separation between OAuth and password flows.Renaming
signuptologinViaOauthand adding theconnectionparameter improves API clarity by distinguishing OAuth-based login from password-based authentication. The redirect-based flow is properly maintained.
32-45: LGTM! Clean password authentication methods.The new
loginandsignupmethods provide straightforward password-based authentication by delegating to the appropriate API endpoints. The method signatures are clear and type-safe.apps/deploy-web/src/hooks/useLoginRequiredEventHandler.tsx (1)
35-35: LGTM! Consistent API usage.Updated to use the renamed
loginViaOauthmethod, maintaining consistency with the AuthService API changes across the codebase.apps/deploy-web/src/components/layout/AccountMenu.tsx (1)
111-111: LGTM! Consistent API usage.Updated to use the renamed
loginViaOauthmethod for the Sign up action, consistent with the AuthService API refactor.apps/deploy-web/src/services/app-di-container/server-di-container.service.ts (2)
31-32: LGTM! Dynamic base URL improves flexibility.Replacing the static base URL with a dynamic lookup via
apiUrlService.getBaseApiUrlFor()ensures the notifications API uses the correct URL for the current managed wallet network.
35-49: LGTM! Proper SessionService configuration.The SessionService is correctly instantiated with:
- External API HTTP client for Auth0 provider calls
- Console API HTTP client with dynamic base URL for internal API calls
- Auth0 configuration with all required credentials (issuer, client ID/secret, audience)
The factory pattern ensures proper initialization with all dependencies.
stalniy
force-pushed
the
feat/embeded-login-api
branch
3 times, most recently
from
8e22024 to
8f41d1d
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
apps/api/src/notifications/services/notification/notification.service.ts (1)
24-26: Update OpenAPI schema to define x-user-id header parameters, then removeas anycastsThe
as anycasts onparametersbypass type safety and violate the TypeScript guideline to avoidany. However, the root cause is that the OpenAPI specification is incomplete—bothcreateNotificationandcreateDefaultChanneloperations are missing thex-user-idheader parameter definition in their specs (currently showing"parameters": []), even though the API backend requires this header for authentication.To properly fix this:
- Update the OpenAPI/Swagger spec to include the
x-user-idheader parameter for both operations inapps/notifications/swagger/swagger.json- Regenerate the TypeScript types from the corrected spec
- Remove the
as anycasts and use the properly typed parametersThis ensures the generated types reflect the actual API requirements and eliminates the need for type casting.
Applies to:
- Line 24-26:
createNotificationcall- Line 46-48:
createDefaultChannelcallapps/deploy-web/src/services/auth/auth/auth.service.spec.ts (1)
15-34: Update nested describe name to match the renamed method.The nested describe block is named
"signup"but testsloginViaOauth(). This creates confusion and doesn't follow the guideline of using method names for nested suite descriptions.- describe("signup", () => { - it("calls signup URL without returnTo parameter", async () => { + describe("loginViaOauth", () => { + it("calls loginViaOauth URL without returnTo parameter", async () => { const { service, httpClient, location } = setup(); await service.loginViaOauth(); expect(httpClient.get).toHaveBeenCalledWith(mockSignupUrl, expect.any(Object)); expect(location.assign).toHaveBeenCalledWith(mockSignupUrl); }); - it("calls signup URL with returnTo parameter", async () => { + it("calls loginViaOauth URL with returnTo parameter", async () => { const { service, httpClient, location } = setup(); const returnTo = "/dashboard"; await service.loginViaOauth({ returnTo }); expect(httpClient.get).toHaveBeenCalledWith(mockSignupUrl, expect.any(Object)); expect(location.assign).toHaveBeenCalledWith(`${mockSignupUrl}?returnTo=${encodeURIComponent(returnTo)}`); }); });Also consider renaming
mockSignupUrltomockLoginUrlormockOauthUrlfor consistency with the renamed method.
♻️ Duplicate comments (1)
apps/deploy-web/next.config.js (1)
74-78: Server-side aliases rely on internal @auth0/nextjs-auth0 module paths.This has been flagged in a previous review. The aliases to
@auth0/nextjs-auth0/sessionand@auth0/nextjs-auth0/update-sessionare v3-specific internal paths that will break when upgrading to v4. The previous review provided migration guidance.
🧹 Nitpick comments (5)
apps/deploy-web/src/services/session/session.service.spec.ts (1)
383-388: Consider extracting mock creation into the setup function.The
createHttpClientMockhelper is defined outside the describe block. While functional, per coding guidelines, mock creation is typically handled within thesetupfunction usingjest-mock-extended. This is already done correctly insidesetup, so this external helper is somewhat redundant.-function createHttpClientMock(): MockProxy<HttpClient> { - return mock<HttpClient>({ - post: jest.fn(), - get: jest.fn() - } as unknown as HttpClient); -} +function createHttpClientMock(): MockProxy<HttpClient> { + return mock<HttpClient>(); +}The explicit
jest.fn()assignments are unnecessary sincemock<HttpClient>()fromjest-mock-extendedalready provides mock implementations for all methods.apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx (2)
14-37: Mutation-based wiring around authService.loginViaOauth looks good; consider guarding duplicate clicks on LinkThe switch to
useMutation<void, Error, React.MouseEvent>withsignup.mutateas the click handler is a clean way to centralize the async flow and pending state;signup.isPendingcorrectly drives both the buttondisabledand linkaria-disabledflags.The only behavioral nit is that the
<Link>can still fire click events while markedaria-disabled, which can trigger multiplemutatecalls while the mutation is pending. If that matters for your UX, you could wrapsignup.mutatewith a small handler that early-returns whensignup.isPendingis true.
7-12: Index signature withanyon Props can be tightened later
[key: string]: any;keeps the component flexible but violates the “noany” guideline and weakens type safety for consumers. Not blocking this PR, but it would be good to replace this with a more specific prop shape or aComponentProps-based helper in a follow-up refactor.apps/deploy-web/src/lib/auth0/setSession/setSession.ts (1)
1-59: Auth0 SessionCache hook-in is reasonable but brittle; tweak error textThe patching of
@auth0/nextjs-auth0/update-sessionto capture a globalSessionCache, then reusing that viasessionModule.setafter forcing an SDK init withgetSession, is a pragmatic way to implementsetSessiongiven the current lack of official support. The flow inensureSessionCacheInitializedandsetSessionis coherent for the API-route use case.Two small points:
- This will be quite sensitive to
@auth0/nextjs-auth0internals; on SDK upgrades, it’s worth re-running the dedicatedsetSessiontests to ensure the aliasing and patch still work.- The thrown error message has a small typo and could be clearer for operators:
- throw new Error("Cannot create session: SessionCache cache was not automatically discovered"); + throw new Error("Cannot create session: SessionCache instance was not automatically discovered");apps/deploy-web/src/pages/api/auth/password-login.ts (1)
1-28: Password-login handler correctly ties sessionService.signIn to setSession; consider 204 semanticsThe handler cleanly validates input with Zod, calls
sessionService.signIn, and on success establishes the Auth0 session viasetSession(req, res, result.val), falling back to a 400 with the error payload whenresult.okis false. The control flow is clear and matches the newAuthService.loginbehavior.One minor HTTP-detail nit: for a
204response it’s more conventional to omit a body entirely, e.g.:- await setSession(req, res, result.val); - res.status(204).json(null); + await setSession(req, res, result.val); + res.status(204).end();This is non-blocking if your clients already handle the current behavior.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (23)
apps/api/src/notifications/services/notification/notification.service.ts(1 hunks)apps/deploy-web/jest.config.ts(3 hunks)apps/deploy-web/next.config.js(3 hunks)apps/deploy-web/package.json(1 hunks)apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx(3 hunks)apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx(2 hunks)apps/deploy-web/src/components/layout/AccountMenu.tsx(1 hunks)apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsx(1 hunks)apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsx(1 hunks)apps/deploy-web/src/hooks/useLoginRequiredEventHandler.tsx(1 hunks)apps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts(1 hunks)apps/deploy-web/src/lib/auth0/setSession/setSession.ts(1 hunks)apps/deploy-web/src/pages/api/auth/[...auth0].ts(4 hunks)apps/deploy-web/src/pages/api/auth/password-login.ts(1 hunks)apps/deploy-web/src/pages/api/auth/password-signup.ts(1 hunks)apps/deploy-web/src/pages/api/auth/signup.ts(1 hunks)apps/deploy-web/src/services/app-di-container/server-di-container.service.ts(2 hunks)apps/deploy-web/src/services/auth/auth/auth.service.spec.ts(2 hunks)apps/deploy-web/src/services/auth/auth/auth.service.ts(2 hunks)apps/deploy-web/src/services/session/session.service.spec.ts(1 hunks)apps/deploy-web/src/services/session/session.service.ts(1 hunks)apps/deploy-web/src/utils/encoding.ts(1 hunks)packages/ui/styles/global.css(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (11)
- apps/deploy-web/package.json
- apps/deploy-web/src/pages/api/auth/password-signup.ts
- apps/deploy-web/src/hooks/useLoginRequiredEventHandler.tsx
- apps/deploy-web/src/utils/encoding.ts
- packages/ui/styles/global.css
- apps/deploy-web/jest.config.ts
- apps/deploy-web/src/pages/api/auth/[...auth0].ts
- apps/deploy-web/src/services/app-di-container/server-di-container.service.ts
- apps/deploy-web/src/pages/api/auth/signup.ts
- apps/deploy-web/src/services/session/session.service.ts
- apps/deploy-web/src/components/layout/AccountMenu.tsx
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (.cursor/rules/general.mdc)
**/*.{ts,tsx,js}: Never use typeanyor cast to typeany. Always define the proper TypeScript types.
Never use deprecated methods from libraries.
Don't add unnecessary comments to the code.
Files:
apps/deploy-web/src/services/auth/auth/auth.service.spec.tsapps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsxapps/deploy-web/src/services/session/session.service.spec.tsapps/deploy-web/src/lib/auth0/setSession/setSession.tsapps/deploy-web/src/services/auth/auth/auth.service.tsapps/deploy-web/src/lib/auth0/setSession/setSession.spec.tsapps/deploy-web/src/pages/api/auth/password-login.tsapps/deploy-web/next.config.jsapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsxapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsxapps/api/src/notifications/services/notification/notification.service.tsapps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsx
**/*.spec.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/no-jest-mock.mdc)
Don't use
jest.mock()in test files. Instead, usejest-mock-extendedto create mocks and pass mocks as dependencies to the service under testUse
setupfunction instead ofbeforeEachin test files. Thesetupfunction must be at the bottom of the rootdescribeblock, should create an object under test and return it, accept a single parameter with inline type definition, avoid shared state, and not have a specified return type.
**/*.spec.{ts,tsx}: Use<Subject>.namein the root describe suite description instead of hardcoded class/service name strings to enable automated refactoring tools to find all references
Use either a method name or a condition starting with 'when' for nested suite descriptions in tests
Use present simple, 3rd person singular for test descriptions without prepending 'should'
Files:
apps/deploy-web/src/services/auth/auth/auth.service.spec.tsapps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsxapps/deploy-web/src/services/session/session.service.spec.tsapps/deploy-web/src/lib/auth0/setSession/setSession.spec.tsapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx
{apps/deploy-web,apps/provider-console}/**/*.spec.tsx
📄 CodeRabbit inference engine (.cursor/rules/query-by-in-tests.mdc)
Use
queryBymethods instead ofgetBymethods in test expectations
Files:
apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsxapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx
🧠 Learnings (8)
📚 Learning: 2025-11-25T17:45:49.180Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/query-by-in-tests.mdc:0-0
Timestamp: 2025-11-25T17:45:49.180Z
Learning: Applies to {apps/deploy-web,apps/provider-console}/**/*.spec.tsx : Use `queryBy` methods instead of `getBy` methods in test expectations
Applied to files:
apps/deploy-web/src/services/auth/auth/auth.service.spec.tsapps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsxapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx
📚 Learning: 2025-11-25T17:45:52.965Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/setup-instead-of-before-each.mdc:0-0
Timestamp: 2025-11-25T17:45:52.965Z
Learning: Applies to **/*.spec.{ts,tsx} : Use `setup` function instead of `beforeEach` in test files. The `setup` function must be at the bottom of the root `describe` block, should create an object under test and return it, accept a single parameter with inline type definition, avoid shared state, and not have a specified return type.
Applied to files:
apps/deploy-web/src/services/auth/auth/auth.service.spec.tsapps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsxapps/deploy-web/src/lib/auth0/setSession/setSession.spec.tsapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx
📚 Learning: 2025-11-25T17:45:44.790Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/no-jest-mock.mdc:0-0
Timestamp: 2025-11-25T17:45:44.790Z
Learning: Applies to **/*.spec.{ts,tsx} : Don't use `jest.mock()` in test files. Instead, use `jest-mock-extended` to create mocks and pass mocks as dependencies to the service under test
Applied to files:
apps/deploy-web/src/services/auth/auth/auth.service.spec.tsapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx
📚 Learning: 2025-11-25T17:45:58.258Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/test-descriptions.mdc:0-0
Timestamp: 2025-11-25T17:45:58.258Z
Learning: Applies to **/*.spec.{ts,tsx} : Use `<Subject>.name` in the root describe suite description instead of hardcoded class/service name strings to enable automated refactoring tools to find all references
Applied to files:
apps/deploy-web/src/services/auth/auth/auth.service.spec.tsapps/deploy-web/src/services/session/session.service.spec.tsapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx
📚 Learning: 2025-07-11T10:46:43.711Z
Learnt from: stalniy
Repo: akash-network/console PR: 1660
File: apps/deploy-web/src/components/alerts/DeploymentAlertsContainer/DeploymentAlertsContainer.spec.tsx:54-56
Timestamp: 2025-07-11T10:46:43.711Z
Learning: In apps/{deploy-web,provider-console}/**/*.spec.tsx files: Use `getBy` methods instead of `queryBy` methods when testing element presence with `toBeInTheDocument()` because `getBy` throws an error and shows DOM state when element is not found, providing better debugging information than `queryBy` which returns null.
Applied to files:
apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsxapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx
📚 Learning: 2025-08-12T13:52:38.708Z
Learnt from: stalniy
Repo: akash-network/console PR: 1800
File: apps/deploy-web/next.config.js:163-165
Timestamp: 2025-08-12T13:52:38.708Z
Learning: In the Akash Console project, akashnetwork/env-loader is used at the top of next.config.js files to automatically load environment variables from env/.env files into process.env. SENTRY_ORG and SENTRY_PROJECT are stored as public configuration values in apps/deploy-web/env/.env and are loaded this way, while only SENTRY_AUTH_TOKEN is handled as a GitHub secret in workflows.
Applied to files:
apps/deploy-web/next.config.js
📚 Learning: 2025-09-10T08:40:53.104Z
Learnt from: stalniy
Repo: akash-network/console PR: 1892
File: apps/deploy-web/src/components/new-deployment/BidCountdownTimer.tsx:20-31
Timestamp: 2025-09-10T08:40:53.104Z
Learning: In TanStack Query v5, the onSuccess and onError callbacks were removed from useQuery options. Instead, use useEffect with the data as a dependency to handle side effects when query data changes.
Applied to files:
apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx
📚 Learning: 2025-11-12T16:36:02.543Z
Learnt from: baktun14
Repo: akash-network/console PR: 2203
File: apps/deploy-web/src/components/onboarding/steps/PaymentMethodContainer/PaymentMethodContainer.tsx:161-168
Timestamp: 2025-11-12T16:36:02.543Z
Learning: In apps/deploy-web/src/components/onboarding/steps/PaymentMethodContainer/PaymentMethodContainer.tsx, the organization field captured during payment method setup is internal metadata. Errors from stripe.updateCustomerOrganization should be logged to Sentry but not surfaced to users, and the flow should continue even if the organization update fails, as it's non-critical and not something users can fix.
Applied to files:
apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsx
🧬 Code graph analysis (4)
apps/deploy-web/src/services/auth/auth/auth.service.ts (1)
apps/deploy-web/src/services/session/session.service.ts (1)
input(33-90)
apps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts (1)
apps/deploy-web/src/lib/auth0/setSession/setSession.ts (1)
setSession(47-59)
apps/deploy-web/next.config.js (1)
apps/stats-web/next.config.js (2)
require(2-2)require(5-5)
apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx (2)
apps/deploy-web/src/services/auth/auth/auth.service.ts (1)
signup(39-45)packages/ui/components/button.tsx (1)
Button(46-46)
⏰ 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). (13)
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: validate (apps/provider-proxy) / validate-unsafe
- GitHub Check: test-build
- GitHub Check: test-build
- GitHub Check: test-build
- GitHub Check: test-build
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: Validate local packages
🔇 Additional comments (14)
apps/api/src/notifications/services/notification/notification.service.ts (1)
6-11: ReducednumOfAttemptsto 5: verified as reasonable latency vs reliability tradeoffWith
startingDelay: 500,timeMultiple: 2, andmaxDelay: 5_000, droppingnumOfAttemptsfrom 10 to 5 reduces worst-case wait from ~38–40s to ~13–15s per operation. This sharedDEFAULT_BACKOFF_OPTIONSconfiguration is used in bothcreateNotification(line 38) andcreateDefaultChannel(line 65), and 5 attempts should be acceptable for transient failures in both flows without requiring separate configurations.apps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts (1)
1-21: LGTM! Test structure follows coding guidelines.The test correctly:
- Uses
setSession.namein the describe block for refactoring tool compatibility- Uses
jest-mock-extendedfor mocking instead ofjest.mock()- Sets up Auth0 environment variables before import (required since the library reads them at import time)
One minor observation: the test description "can set session" could be rephrased to present simple 3rd person (e.g., "sets session and retrieves it via getSession"). However, this is a nitpick given the test is clear and functional.
apps/deploy-web/next.config.js (2)
12-12: LGTM on path import addition.The
pathmodule import is correctly added to support the webpack alias configuration.
24-24: LGTM on transpilePackages addition.Adding
@auth0/nextjs-auth0to transpilePackages ensures proper transpilation of the library for compatibility with the project's build configuration.apps/deploy-web/src/services/session/session.service.spec.ts (5)
11-11: LGTM! Root describe usesSessionService.nameas per coding guidelines.
365-380: LGTM! Setup function follows coding guidelines.The
setupfunction:
- Is positioned at the bottom of the root
describeblock- Creates and returns the object under test
- Accepts a single parameter with inline type definition
- Avoids shared state
- Has no explicit return type
12-125: LGTM! signIn tests are comprehensive.The tests cover:
- Success path with token exchange, userinfo fetch, and local user enrichment
- Error path with proper error code mapping
- API call verification with correct endpoints and headers
- validateStatus function behavior verification
Test descriptions follow the guideline of using method names for nested describes and present simple 3rd person for test cases.
127-288: LGTM! signUp tests cover key scenarios.The tests properly validate:
- Password policy violations returning appropriate error codes
- Generic signup failures with descriptive error messages
- Successful signup flow including token exchange and local user creation
290-363: LGTM! createLocalUser and getLocalUserDetails tests are well-structured.Both tests verify correct API endpoints and authorization headers.
apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsx (1)
175-175: LGTM! Method call updated to match renamed auth service API.The change from
authService.signup()toauthService.loginViaOauth()aligns with the broader PR refactoring of the authentication service API.apps/deploy-web/src/services/auth/auth/auth.service.spec.ts (1)
93-112: LGTM! Setup function follows coding guidelines.The
setupfunction is correctly positioned at the bottom of the root describe block, creates the object under test, accepts a single parameter pattern (none required here), avoids shared state, and has no explicit return type.apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsx (1)
68-84: Onboarding now asserting loginViaOauth with onboarding returnTo – looks consistentThe expectation correctly reflects the switch from
signuptologinViaOauthand still verifies that thereturnToURL targets the onboarding path, so the test remains aligned with the updated auth flow.apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx (1)
48-79: Tests correctly migrated to loginViaOauth and keep type safetyBoth tests now validate
authService.loginViaOauthbeing called for link and button variants, andsetup’ssignup?: AuthService["loginViaOauth"]plusmock<AuthService>({ loginViaOauth: signup })keeps the wiring type-safe and aligned with the new AuthService API.apps/deploy-web/src/services/auth/auth/auth.service.ts (1)
15-45: New OAuth + password login/signup methods are wired coherentlyExtending
loginViaOauthto accept an optionalconnectionparameter and passing it viaURLSearchParamskeeps the redirect semantics intact while enabling provider selection. The newloginandsignupmethods cleanly delegate to/api/auth/password-loginand/api/auth/password-signupwith minimal, well-typed payloads and no extra coupling to the underlying session logic.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (3)
apps/deploy-web/src/pages/api/auth/signup.ts (1)
40-48: Normalizeconnectionquery param and avoidanyin error handling
req.query.connectionisstring | string[] | undefined, but it’s cast directly tostring | undefinedand passed toauthorizationParams.connection. If a client sends multipleconnectionvalues (e.g.?connection=a&connection=b), an array will be forwarded to Auth0, which expects a single string.At the same time,
catch (error: any)breaks the “noany” guideline and loses type safety when inspectingerror.statusanderror.message.Consider:
const rawConnection = req.query.connection; const connection = typeof rawConnection === "string" ? rawConnection : Array.isArray(rawConnection) ? rawConnection[0] : undefined; await handleLogin(req, res, { returnTo: returnUrl, authorizationParams: { action: "signup", connection } });And change the catch to use
unknownplus narrowing, e.g.:} catch (error: unknown) { let severity: SeverityLevel = "error"; const status = typeof error === "object" && error !== null && "status" in error ? (error as { status?: number }).status : undefined; if (typeof status === "number" && status >= 400 && status < 500) { severity = "warning"; res.status(400).send({ message: (error as { message?: string }).message ?? "Bad request" }); } else { res.status(503).send({ message: "An unexpected error occurred. Please try again later." }); } services.errorHandler.reportError({ severity, error, tags: { category: "auth0", event: "AUTH_SIGNUP_ERROR" } }); }This keeps behavior the same while guarding against malformed query values and preserving type safety.
What is the type of `req.query` in Next.js API routes, and what type does Auth0’s `authorizationParams.connection` expect in `@auth0/nextjs-auth0`?apps/deploy-web/next.config.js (1)
12-12: Auth0 internal module aliases are v3-specific; plan for future migrationThe server-side webpack aliases for
@auth0/nextjs-auth0/sessionand@auth0/nextjs-auth0/update-session, combined with transpiling@auth0/nextjs-auth0, are necessary for the currentsetSessionworkaround, but they hard‑wire the build to v3’s internal module layout. A future upgrade to v4 (or any change in internal paths) will break this configuration.To avoid surprises when bumping
@auth0/nextjs-auth0, keep the dependency pinned to the version whose internals you target and plan a dedicated migration to the public v4 server APIs (session hooks /updateSessionreplacements) before changing major versions.This mirrors earlier feedback on the same aliasing approach.
What are the supported public APIs for session creation/update in `@auth0/nextjs-auth0` v3 vs v4, and are the internal paths `@auth0/nextjs-auth0/session` and `@auth0/nextjs-auth0/update-session` considered stable?Also applies to: 24-24, 61-78
apps/deploy-web/src/services/session/session.service.ts (1)
184-190: Add error handling for malformed JWT tokens.The
getClaimsFromTokenfunction can throw if the token is malformed (missing payload segment, invalid base64, or invalid JSON). Consider adding guards.function getClaimsFromToken(token: string) { - const stringifiedClaims = decoder.decode(fromBase64Url(token.split(".").at(1) || "")); - const claims = JSON.parse(stringifiedClaims, (key, value) => { - if (IDENTITY_CLAIM_FILTER.has(key)) return undefined; - return value; - }); - return claims; + const payload = token.split(".").at(1); + if (!payload) { + throw new Error("Invalid token: missing payload segment"); + } + try { + const stringifiedClaims = decoder.decode(fromBase64Url(payload)); + const claims = JSON.parse(stringifiedClaims, (key, value) => { + if (IDENTITY_CLAIM_FILTER.has(key)) return undefined; + return value; + }); + return claims; + } catch (error) { + throw new Error("Invalid token: failed to decode claims", { cause: error }); + } }
🧹 Nitpick comments (8)
apps/deploy-web/src/utils/encoding.ts (1)
23-27: Implementation is correct.The Base64 URL decoding logic correctly handles the conversion (replacing
-with+and_with/) and padding calculation. The delegation tofromBase64promotes code reuse.Consider verifying whether
@cosmjs/encodingor another existing project dependency already provides Base64 URL decoding functionality. While this implementation is correct and concise, leveraging an existing library function would align with the coding guideline to prefer well-known libraries for common operations.#!/bin/bash # Check if @cosmjs/encoding exports Base64 URL utilities rg -n "fromBase64Url|decodeBase64Url" node_modules/@cosmjs/encoding -A 2 -B 2apps/deploy-web/src/services/app-di-container/server-di-container.service.ts (1)
12-12: Centralize console API HttpClient configuration to avoid duplication
notificationsApi,consoleApiHttpClient, and theSessionServiceconstructor all derive console API clients, andSessionServicebuilds its own axios instance with a base URL instead of reusingconsoleApiHttpClient. This risks config drift (interceptors, base URL, timeouts) if one is updated but not the others.Consider configuring the base URL once in
consoleApiHttpClient(usingapiUrlService.getBaseApiUrlFor(...)) and passingservices.consoleApiHttpClientintoSessionServiceinstead of constructing a separate axios instance there.Also applies to: 31-31, 34-49
apps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts (1)
1-21: End‑to‑end test for setSession is clear and follows local patternsThe test cleanly verifies that
setSessionwires through togetSessionand usesjest-mock-extendedplusdescribe(setSession.name), which matches the repo’s testing conventions. If you ever start using the "direct session" mode (without req/res) insetSession, consider adding a second test for that path; otherwise this looks good as‑is.apps/deploy-web/src/lib/auth0/setSession/setSession.ts (1)
24-29: TightensetSessionAPI to avoid ambiguous call patterns
setSessioncurrently overloads behavior via(reqOrSession: NextApiRequest | Session, res: NextApiResponse | undefined, newSession: Session), assuming callers always pass a consistent combination of arguments. Misuse (e.g., passing aSessionwith a non‑undefinedres, or forgetting to passnewSession) won’t be caught at compile time and may behave unexpectedly at runtime.Consider using TypeScript overloads plus a single implementation to make the API shapes explicit and safer:
export async function setSession(req: NextApiRequest, res: NextApiResponse, session: Session): Promise<void>; export async function setSession(session: Session): Promise<void>; export async function setSession( reqOrSession: NextApiRequest | Session, res?: NextApiResponse, newSession?: Session ): Promise<void> { const isApiRouteMode = !!res; const req = isApiRouteMode ? (reqOrSession as NextApiRequest) : undefined; const session = isApiRouteMode ? (newSession as Session) : (reqOrSession as Session); // existing logic... }This keeps the current behavior but lets the compiler enforce correct call sites and reduces the chance of accidental misuse.
Also applies to: 31-45, 47-58
apps/deploy-web/src/pages/api/auth/password-signup.ts (1)
36-40: Usebodyfrom handler context instead ofreq.bodyThe
defineApiHandlerprovides a validated and typedbodyproperty directly in the handler context. Accessingreq.bodybypasses this and loses TypeScript type inference.- async handler({ res, req, services }) { + async handler({ res, req, body, services }) { const result = await services.sessionService.signUp({ - email: req.body.email, - password: req.body.password + email: body.email, + password: body.password });apps/deploy-web/src/services/session/session.service.spec.ts (1)
383-388: Consider simplifying the mock creation.The
mock<HttpClient>already creates a mock with all methods stubbed. The explicitjest.fn()assignments and cast are redundant.function createHttpClientMock(): MockProxy<HttpClient> { - return mock<HttpClient>({ - post: jest.fn(), - get: jest.fn() - } as unknown as HttpClient); + return mock<HttpClient>(); }apps/deploy-web/src/pages/api/auth/password-login.ts (1)
14-18: Usebodyfrom handler context instead ofreq.bodySame as the signup endpoint, the handler should destructure
bodyfrom context for type safety and consistency.- async handler({ res, req, services }) { + async handler({ res, req, body, services }) { const result = await services.sessionService.signIn({ - email: req.body.email, - password: req.body.password + email: body.email, + password: body.password });apps/deploy-web/src/services/session/session.service.ts (1)
140-140: Consider extracting the user metadata namespace as a constant.The namespace
"https://console.akash.network/user_metadata"is used here and also appears in the test file. Extracting it to a shared constant improves maintainability.+const USER_METADATA_KEY = "https://console.akash.network/user_metadata" as const; + export class SessionService { // ... async createLocalUser(session: Session): Promise<UserSettings> { - const user_metadata = session.user["https://console.akash.network/user_metadata"]; + const user_metadata = session.user[USER_METADATA_KEY];
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (23)
apps/api/src/notifications/services/notification/notification.service.ts(1 hunks)apps/deploy-web/jest.config.ts(3 hunks)apps/deploy-web/next.config.js(3 hunks)apps/deploy-web/package.json(1 hunks)apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx(3 hunks)apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx(2 hunks)apps/deploy-web/src/components/layout/AccountMenu.tsx(1 hunks)apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsx(1 hunks)apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsx(1 hunks)apps/deploy-web/src/hooks/useLoginRequiredEventHandler.tsx(1 hunks)apps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts(1 hunks)apps/deploy-web/src/lib/auth0/setSession/setSession.ts(1 hunks)apps/deploy-web/src/pages/api/auth/[...auth0].ts(4 hunks)apps/deploy-web/src/pages/api/auth/password-login.ts(1 hunks)apps/deploy-web/src/pages/api/auth/password-signup.ts(1 hunks)apps/deploy-web/src/pages/api/auth/signup.ts(1 hunks)apps/deploy-web/src/services/app-di-container/server-di-container.service.ts(2 hunks)apps/deploy-web/src/services/auth/auth/auth.service.spec.ts(2 hunks)apps/deploy-web/src/services/auth/auth/auth.service.ts(2 hunks)apps/deploy-web/src/services/session/session.service.spec.ts(1 hunks)apps/deploy-web/src/services/session/session.service.ts(1 hunks)apps/deploy-web/src/utils/encoding.ts(1 hunks)packages/ui/styles/global.css(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (8)
- apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsx
- apps/api/src/notifications/services/notification/notification.service.ts
- apps/deploy-web/src/services/auth/auth/auth.service.spec.ts
- apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsx
- apps/deploy-web/src/hooks/useLoginRequiredEventHandler.tsx
- apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx
- apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx
- packages/ui/styles/global.css
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (.cursor/rules/general.mdc)
**/*.{ts,tsx,js}: Never use typeanyor cast to typeany. Always define the proper TypeScript types.
Never use deprecated methods from libraries.
Don't add unnecessary comments to the code.
Files:
apps/deploy-web/src/pages/api/auth/password-signup.tsapps/deploy-web/src/components/layout/AccountMenu.tsxapps/deploy-web/jest.config.tsapps/deploy-web/next.config.jsapps/deploy-web/src/services/session/session.service.spec.tsapps/deploy-web/src/utils/encoding.tsapps/deploy-web/src/services/session/session.service.tsapps/deploy-web/src/services/auth/auth/auth.service.tsapps/deploy-web/src/services/app-di-container/server-di-container.service.tsapps/deploy-web/src/pages/api/auth/[...auth0].tsapps/deploy-web/src/pages/api/auth/password-login.tsapps/deploy-web/src/lib/auth0/setSession/setSession.tsapps/deploy-web/src/pages/api/auth/signup.tsapps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts
**/*.spec.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/no-jest-mock.mdc)
Don't use
jest.mock()in test files. Instead, usejest-mock-extendedto create mocks and pass mocks as dependencies to the service under testUse
setupfunction instead ofbeforeEachin test files. Thesetupfunction must be at the bottom of the rootdescribeblock, should create an object under test and return it, accept a single parameter with inline type definition, avoid shared state, and not have a specified return type.
**/*.spec.{ts,tsx}: Use<Subject>.namein the root describe suite description instead of hardcoded class/service name strings to enable automated refactoring tools to find all references
Use either a method name or a condition starting with 'when' for nested suite descriptions in tests
Use present simple, 3rd person singular for test descriptions without prepending 'should'
Files:
apps/deploy-web/src/services/session/session.service.spec.tsapps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts
🧠 Learnings (5)
📚 Learning: 2025-11-25T17:45:44.790Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/no-jest-mock.mdc:0-0
Timestamp: 2025-11-25T17:45:44.790Z
Learning: Applies to **/*.spec.{ts,tsx} : Don't use `jest.mock()` in test files. Instead, use `jest-mock-extended` to create mocks and pass mocks as dependencies to the service under test
Applied to files:
apps/deploy-web/jest.config.ts
📚 Learning: 2025-11-25T17:45:52.965Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/setup-instead-of-before-each.mdc:0-0
Timestamp: 2025-11-25T17:45:52.965Z
Learning: Applies to **/*.spec.{ts,tsx} : Use `setup` function instead of `beforeEach` in test files. The `setup` function must be at the bottom of the root `describe` block, should create an object under test and return it, accept a single parameter with inline type definition, avoid shared state, and not have a specified return type.
Applied to files:
apps/deploy-web/jest.config.tsapps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts
📚 Learning: 2025-11-25T17:45:58.258Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/test-descriptions.mdc:0-0
Timestamp: 2025-11-25T17:45:58.258Z
Learning: Applies to **/*.spec.{ts,tsx} : Use either a method name or a condition starting with 'when' for nested suite descriptions in tests
Applied to files:
apps/deploy-web/jest.config.ts
📚 Learning: 2025-08-12T13:52:38.708Z
Learnt from: stalniy
Repo: akash-network/console PR: 1800
File: apps/deploy-web/next.config.js:163-165
Timestamp: 2025-08-12T13:52:38.708Z
Learning: In the Akash Console project, akashnetwork/env-loader is used at the top of next.config.js files to automatically load environment variables from env/.env files into process.env. SENTRY_ORG and SENTRY_PROJECT are stored as public configuration values in apps/deploy-web/env/.env and are loaded this way, while only SENTRY_AUTH_TOKEN is handled as a GitHub secret in workflows.
Applied to files:
apps/deploy-web/next.config.js
📚 Learning: 2025-11-25T17:45:58.258Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/test-descriptions.mdc:0-0
Timestamp: 2025-11-25T17:45:58.258Z
Learning: Applies to **/*.spec.{ts,tsx} : Use `<Subject>.name` in the root describe suite description instead of hardcoded class/service name strings to enable automated refactoring tools to find all references
Applied to files:
apps/deploy-web/src/services/session/session.service.spec.ts
🧬 Code graph analysis (8)
apps/deploy-web/src/pages/api/auth/password-signup.ts (3)
apps/deploy-web/src/lib/nextjs/defineApiHandler/defineApiHandler.ts (1)
defineApiHandler(13-53)apps/deploy-web/src/services/app-di-container/server-di-container.service.ts (1)
services(24-50)apps/deploy-web/src/lib/auth0/setSession/setSession.ts (1)
setSession(47-59)
apps/deploy-web/src/services/session/session.service.spec.ts (2)
apps/deploy-web/src/services/session/session.service.ts (1)
OauthConfig(170-175)apps/deploy-web/src/types/user.ts (1)
UserSettings(5-17)
apps/deploy-web/src/services/session/session.service.ts (2)
apps/deploy-web/src/types/user.ts (1)
UserSettings(5-17)apps/deploy-web/src/utils/encoding.ts (1)
fromBase64Url(23-27)
apps/deploy-web/src/services/auth/auth/auth.service.ts (1)
apps/deploy-web/src/services/session/session.service.ts (1)
input(33-89)
apps/deploy-web/src/services/app-di-container/server-di-container.service.ts (1)
apps/deploy-web/src/services/session/session.service.ts (1)
SessionService(9-168)
apps/deploy-web/src/pages/api/auth/[...auth0].ts (1)
apps/deploy-web/src/services/app-di-container/server-di-container.service.ts (1)
services(24-50)
apps/deploy-web/src/pages/api/auth/password-login.ts (3)
apps/deploy-web/src/lib/nextjs/defineApiHandler/defineApiHandler.ts (1)
defineApiHandler(13-53)apps/deploy-web/src/services/app-di-container/server-di-container.service.ts (1)
services(24-50)apps/deploy-web/src/lib/auth0/setSession/setSession.ts (1)
setSession(47-59)
apps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts (1)
apps/deploy-web/src/lib/auth0/setSession/setSession.ts (1)
setSession(47-59)
⏰ 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). (15)
- GitHub Check: validate (apps/provider-proxy) / validate-unsafe
- GitHub Check: validate (apps/api) / validate-unsafe
- GitHub Check: validate (apps/provider-console) / validate-unsafe
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: test-build
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: test-build
- GitHub Check: validate (apps/deploy-web) / should-validate-unsafe / should-validate
- GitHub Check: test-build
- GitHub Check: Validate local packages
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (12)
apps/deploy-web/package.json (1)
127-127: ts-results dependency is properly used and secure.The dependency is actively used in the new SessionService (
apps/deploy-web/src/services/session/session.service.ts) for functional error handling with the Result pattern. Version 3.3.0 is the latest stable release with no known security vulnerabilities.apps/deploy-web/src/components/layout/AccountMenu.tsx (1)
109-114: OAuth signup wiring now correctly targetsloginViaOauthThe “Sign up” dropdown entry now calls
authService.loginViaOauth(), which aligns with the renamed API and the unified OAuth login/signup flow. No further changes needed here.apps/deploy-web/src/services/auth/auth/auth.service.ts (1)
15-19: AuthService API surface cleanly separates OAuth and password flowsThe updated
loginViaOauthwith optionalconnectionplus the newloginandsignupmethods for password-based flows form a clear, minimal surface:
- OAuth login/signup still goes through the
/api/auth/signuproute with encodedreturnTo/connection.- Password login/signup go via dedicated JSON POST calls to
/api/auth/password-loginand/api/auth/password-signup.The wiring looks consistent with the new backend routes; no changes needed here.
Also applies to: 32-45
apps/deploy-web/src/pages/api/auth/password-signup.ts (1)
6-9: Good use of Unicode property escapes for i18n-friendly password validation.The regex patterns correctly use Unicode categories (
\p{Ll},\p{Lu},\p{Nd}) which ensures the password rules work correctly for international characters.apps/deploy-web/jest.config.ts (2)
40-71: Jest configuration properly separates browser and Node test environments.The configuration correctly routes
lib/auth0tests to the Node environment while excluding them from jsdom tests. The transform patterns ensure Auth0 library modules are processed correctly.
16-18: Verify the module path resolution for Auth0 subpaths at runtime.The path construction on lines 17-18 uses
require.resolve("@auth0/nextjs-auth0")and navigates up with".."to reach sibling directories (session/index.jsandsession/update-session.js). This assumes a specific internal package structure that should be verified when running tests with@auth0/nextjs-auth0@^3.5.0installed to ensure the computed paths resolve correctly.apps/deploy-web/src/services/session/session.service.spec.ts (2)
11-11: Good adherence to test naming conventions.The test file correctly uses
SessionService.namein the root describe, which enables automated refactoring tools to find all references. Based on learnings.
365-380: Well-structured setup function following project conventions.The
setupfunction is correctly positioned at the bottom of the root describe block, accepts a single parameter with inline type definition, avoids shared state, and has no specified return type. Based on learnings.apps/deploy-web/src/pages/api/auth/password-login.ts (1)
6-27: Endpoint structure looks good.The login endpoint correctly validates input, delegates to
sessionService.signIn, establishes the session on success, and returns appropriate status codes.apps/deploy-web/src/services/session/session.service.ts (3)
33-89: Well-structured OAuth flow with proper error handling.The
#signInOnProvidermethod correctly handles the OAuth token exchange, userinfo fetch, and session construction. The use ofResulttypes provides clear success/failure paths.
107-119: Error handling correctly distinguishes password policy violations.The signup error handling properly differentiates between
invalid_password(policy violations) and other signup failures, providing appropriate error codes.
177-179:notServerErrorhelper enables graceful 4xx error handling.This pattern allows the service to handle client errors (4xx) without throwing, while still failing on server errors (5xx). Good approach for authentication flows where 401/403 responses are expected.
stalniy
force-pushed
the
feat/embeded-login-api
branch
from
8f41d1d to
3047065
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/api/src/notifications/services/notification/notification.service.spec.ts (1)
149-167: Update the test description to match the new retry count.The test description states "fails after 10 attempts" but the implementation now retries only 5 times.
Apply this diff to fix the inconsistency:
- it("fails after 10 attempts if notification service is not available and logs an error", async () => { + it("fails after 5 attempts if notification service is not available and logs an error", async () => {
♻️ Duplicate comments (3)
apps/deploy-web/src/pages/api/auth/signup.ts (1)
40-44: Guardconnectionquery param and avoiderror: anyThe issues previously flagged remain unaddressed:
req.query.connectionisstring | string[] | undefinedin Next.js, but Auth0'sauthorizationParams.connectionexpectsstring | undefined. Normalize before use.catch (error: any)violates the guideline to never use typeany.authorizationParams: { action: "signup", - connection: req.query.connection as string | undefined + connection: typeof req.query.connection === "string" ? req.query.connection : undefined } }); - } catch (error: any) { + } catch (error: unknown) { + const err = error as { status?: number; message?: string }; let severity: SeverityLevel = "error"; - if (error?.status && error.status >= 400 && error.status < 500) { + if (err?.status && err.status >= 400 && err.status < 500) { severity = "warning"; - res.status(400).send({ message: error.message }); + res.status(400).send({ message: err.message });apps/deploy-web/next.config.js (1)
74-78: Internal module aliasing is fragile and version-sensitiveThese aliases resolve to internal, non-public paths within
@auth0/nextjs-auth0. While functional for v3.5.0, this approach:
- May break on any minor/patch update if Auth0 restructures internal files
- Blocks migration to v4.x which removed these internal paths
The inline comment referencing
setSession.tsfor context is helpful. Consider adding version constraints inpackage.json(e.g.,"@auth0/nextjs-auth0": "~3.5.0") to prevent accidental breakage from updates.@auth0/nextjs-auth0 latest version December 2025apps/deploy-web/src/pages/api/auth/[...auth0].ts (1)
36-36: Normalizeconnectionquery parameter before use.The past review comment about normalizing
req.query.connectionremains valid. In Next.js,req.queryvalues are typed asstring | string[] | undefined. Passing an array to Auth0'sauthorizationParams.connectionwill cause authentication failures.
🧹 Nitpick comments (3)
apps/deploy-web/src/services/auth/auth/auth.service.spec.ts (1)
15-34: Test suite description references "signup" but callsloginViaOauthThe describe block is named
"signup"and tests reference "signup URL", but the method under test is nowloginViaOauth(). Consider renaming for clarity:- describe("signup", () => { - it("calls signup URL without returnTo parameter", async () => { + describe("loginViaOauth", () => { + it("calls OAuth URL without returnTo parameter", async () => { const { service, httpClient, location } = setup(); await service.loginViaOauth(); - expect(httpClient.get).toHaveBeenCalledWith(mockSignupUrl, expect.any(Object)); - expect(location.assign).toHaveBeenCalledWith(mockSignupUrl); + expect(httpClient.get).toHaveBeenCalledWith(mockSignupUrl, expect.any(Object)); + expect(location.assign).toHaveBeenCalledWith(mockSignupUrl); }); - it("calls signup URL with returnTo parameter", async () => { + it("calls OAuth URL with returnTo parameter", async () => {apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx (1)
16-21: Consider movingpreventDefaultto onClick handlers for cleaner separation.The mutation receives a
React.MouseEventand callspreventDefaultwithinmutationFn, which couples UI event handling to the mutation logic. A cleaner pattern would handlepreventDefaultin the onClick handlers and make the mutation independent of browser events.Consider this alternative:
- const signup = useMutation<void, Error, React.MouseEvent>({ - async mutationFn(event) { - event.preventDefault(); + const signup = useMutation({ + async mutationFn() { await authService.loginViaOauth(); } }); + + const handleClick = (event: React.MouseEvent) => { + event.preventDefault(); + signup.mutate(); + };Then update the button and link:
- <Button className={className} onClick={signup.mutate} disabled={signup.isPending} {...props}> + <Button className={className} onClick={handleClick} disabled={signup.isPending} {...props}> {content} </Button> - <Link href="#" passHref prefetch={false} className={className} onClick={signup.mutate} aria-disabled={signup.isPending} {...props}> + <Link href="#" passHref prefetch={false} className={className} onClick={handleClick} aria-disabled={signup.isPending} {...props}> {content} </Link>apps/deploy-web/jest.config.ts (1)
15-18: Auth0 moduleNameMapper entries are sound but tightly coupled to package internalsThe new mappers for
@auth0/nextjs-auth0/sessionandupdate-sessioncorrectly resolve viarequire.resolveandpath.join, which should make Jest match the runtime aliases used in your Auth0 integration. The trade-off is that these paths are now sensitive to changes in the library’s internal folder structure.Consider centralizing these Auth0 path assumptions (e.g., a small helper or shared constant used by both
next.configand Jest config) so future Auth0 upgrades only need one change. Also verify in CI that@auth0/nextjs-auth0is always installed where this config runs, sincerequire.resolvewill throw otherwise.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (24)
apps/api/src/notifications/services/notification/notification.service.spec.ts(2 hunks)apps/api/src/notifications/services/notification/notification.service.ts(1 hunks)apps/deploy-web/jest.config.ts(3 hunks)apps/deploy-web/next.config.js(3 hunks)apps/deploy-web/package.json(1 hunks)apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx(3 hunks)apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx(2 hunks)apps/deploy-web/src/components/layout/AccountMenu.tsx(1 hunks)apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsx(1 hunks)apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsx(1 hunks)apps/deploy-web/src/hooks/useLoginRequiredEventHandler.tsx(1 hunks)apps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts(1 hunks)apps/deploy-web/src/lib/auth0/setSession/setSession.ts(1 hunks)apps/deploy-web/src/pages/api/auth/[...auth0].ts(4 hunks)apps/deploy-web/src/pages/api/auth/password-login.ts(1 hunks)apps/deploy-web/src/pages/api/auth/password-signup.ts(1 hunks)apps/deploy-web/src/pages/api/auth/signup.ts(1 hunks)apps/deploy-web/src/services/app-di-container/server-di-container.service.ts(2 hunks)apps/deploy-web/src/services/auth/auth/auth.service.spec.ts(2 hunks)apps/deploy-web/src/services/auth/auth/auth.service.ts(2 hunks)apps/deploy-web/src/services/session/session.service.spec.ts(1 hunks)apps/deploy-web/src/services/session/session.service.ts(1 hunks)apps/deploy-web/src/utils/encoding.ts(1 hunks)packages/ui/styles/global.css(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (7)
- apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.spec.tsx
- apps/deploy-web/src/services/session/session.service.spec.ts
- apps/deploy-web/src/utils/encoding.ts
- apps/deploy-web/src/components/layout/AccountMenu.tsx
- apps/deploy-web/src/services/session/session.service.ts
- apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.spec.tsx
- apps/deploy-web/package.json
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (.cursor/rules/general.mdc)
**/*.{ts,tsx,js}: Never use typeanyor cast to typeany. Always define the proper TypeScript types.
Never use deprecated methods from libraries.
Don't add unnecessary comments to the code.
Files:
apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsxapps/deploy-web/src/hooks/useLoginRequiredEventHandler.tsxapps/api/src/notifications/services/notification/notification.service.spec.tsapps/deploy-web/src/pages/api/auth/signup.tsapps/deploy-web/src/services/auth/auth/auth.service.spec.tsapps/deploy-web/src/services/app-di-container/server-di-container.service.tsapps/deploy-web/next.config.jsapps/deploy-web/src/pages/api/auth/password-signup.tsapps/deploy-web/src/pages/api/auth/password-login.tsapps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsxapps/deploy-web/src/services/auth/auth/auth.service.tsapps/deploy-web/src/lib/auth0/setSession/setSession.tsapps/deploy-web/src/pages/api/auth/[...auth0].tsapps/api/src/notifications/services/notification/notification.service.tsapps/deploy-web/src/lib/auth0/setSession/setSession.spec.tsapps/deploy-web/jest.config.ts
**/*.spec.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/no-jest-mock.mdc)
Don't use
jest.mock()in test files. Instead, usejest-mock-extendedto create mocks and pass mocks as dependencies to the service under testUse
setupfunction instead ofbeforeEachin test files. Thesetupfunction must be at the bottom of the rootdescribeblock, should create an object under test and return it, accept a single parameter with inline type definition, avoid shared state, and not have a specified return type.
**/*.spec.{ts,tsx}: Use<Subject>.namein the root describe suite description instead of hardcoded class/service name strings to enable automated refactoring tools to find all references
Use either a method name or a condition starting with 'when' for nested suite descriptions in tests
Use present simple, 3rd person singular for test descriptions without prepending 'should'
Files:
apps/api/src/notifications/services/notification/notification.service.spec.tsapps/deploy-web/src/services/auth/auth/auth.service.spec.tsapps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts
🧠 Learnings (8)
📚 Learning: 2025-11-12T16:36:02.543Z
Learnt from: baktun14
Repo: akash-network/console PR: 2203
File: apps/deploy-web/src/components/onboarding/steps/PaymentMethodContainer/PaymentMethodContainer.tsx:161-168
Timestamp: 2025-11-12T16:36:02.543Z
Learning: In apps/deploy-web/src/components/onboarding/steps/PaymentMethodContainer/PaymentMethodContainer.tsx, the organization field captured during payment method setup is internal metadata. Errors from stripe.updateCustomerOrganization should be logged to Sentry but not surfaced to users, and the flow should continue even if the organization update fails, as it's non-critical and not something users can fix.
Applied to files:
apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsx
📚 Learning: 2025-11-25T17:45:49.180Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/query-by-in-tests.mdc:0-0
Timestamp: 2025-11-25T17:45:49.180Z
Learning: Applies to {apps/deploy-web,apps/provider-console}/**/*.spec.tsx : Use `queryBy` methods instead of `getBy` methods in test expectations
Applied to files:
apps/deploy-web/src/services/auth/auth/auth.service.spec.ts
📚 Learning: 2025-08-12T13:52:38.708Z
Learnt from: stalniy
Repo: akash-network/console PR: 1800
File: apps/deploy-web/next.config.js:163-165
Timestamp: 2025-08-12T13:52:38.708Z
Learning: In the Akash Console project, akashnetwork/env-loader is used at the top of next.config.js files to automatically load environment variables from env/.env files into process.env. SENTRY_ORG and SENTRY_PROJECT are stored as public configuration values in apps/deploy-web/env/.env and are loaded this way, while only SENTRY_AUTH_TOKEN is handled as a GitHub secret in workflows.
Applied to files:
apps/deploy-web/next.config.js
📚 Learning: 2025-09-10T08:40:53.104Z
Learnt from: stalniy
Repo: akash-network/console PR: 1892
File: apps/deploy-web/src/components/new-deployment/BidCountdownTimer.tsx:20-31
Timestamp: 2025-09-10T08:40:53.104Z
Learning: In TanStack Query v5, the onSuccess and onError callbacks were removed from useQuery options. Instead, use useEffect with the data as a dependency to handle side effects when query data changes.
Applied to files:
apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx
📚 Learning: 2025-11-25T17:45:52.965Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/setup-instead-of-before-each.mdc:0-0
Timestamp: 2025-11-25T17:45:52.965Z
Learning: Applies to **/*.spec.{ts,tsx} : Use `setup` function instead of `beforeEach` in test files. The `setup` function must be at the bottom of the root `describe` block, should create an object under test and return it, accept a single parameter with inline type definition, avoid shared state, and not have a specified return type.
Applied to files:
apps/deploy-web/src/lib/auth0/setSession/setSession.spec.tsapps/deploy-web/jest.config.ts
📚 Learning: 2025-11-25T17:45:44.790Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/no-jest-mock.mdc:0-0
Timestamp: 2025-11-25T17:45:44.790Z
Learning: Applies to **/*.spec.{ts,tsx} : Don't use `jest.mock()` in test files. Instead, use `jest-mock-extended` to create mocks and pass mocks as dependencies to the service under test
Applied to files:
apps/deploy-web/jest.config.ts
📚 Learning: 2025-11-25T17:45:39.561Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/general.mdc:0-0
Timestamp: 2025-11-25T17:45:39.561Z
Learning: Applies to **/*.{ts,tsx,js} : Don't add unnecessary comments to the code.
Applied to files:
apps/deploy-web/jest.config.ts
📚 Learning: 2025-11-25T17:45:58.258Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/test-descriptions.mdc:0-0
Timestamp: 2025-11-25T17:45:58.258Z
Learning: Applies to **/*.spec.{ts,tsx} : Use either a method name or a condition starting with 'when' for nested suite descriptions in tests
Applied to files:
apps/deploy-web/jest.config.ts
🧬 Code graph analysis (6)
apps/deploy-web/src/pages/api/auth/password-signup.ts (3)
apps/deploy-web/src/lib/nextjs/defineApiHandler/defineApiHandler.ts (1)
defineApiHandler(13-53)apps/deploy-web/src/services/app-di-container/server-di-container.service.ts (1)
services(24-50)apps/deploy-web/src/lib/auth0/setSession/setSession.ts (1)
setSession(47-59)
apps/deploy-web/src/components/auth/SignUpButton/SignUpButton.tsx (2)
apps/deploy-web/src/services/auth/auth/auth.service.ts (1)
signup(39-45)packages/ui/components/button.tsx (1)
Button(46-46)
apps/deploy-web/src/services/auth/auth/auth.service.ts (1)
apps/deploy-web/src/services/session/session.service.ts (1)
input(33-89)
apps/deploy-web/src/pages/api/auth/[...auth0].ts (2)
apps/deploy-web/src/services/app-di-container/server-di-container.service.ts (1)
services(24-50)apps/deploy-web/src/services/app-di-container/browser-di-container.ts (1)
services(24-59)
apps/deploy-web/src/lib/auth0/setSession/setSession.spec.ts (3)
apps/deploy-web/src/lib/auth0/setSession/setSession.ts (1)
setSession(47-59)apps/notifications/script/init-db.js (1)
res(24-24)apps/deploy-web/tests/ui/fixture/context-with-extension.ts (1)
expect(78-78)
apps/deploy-web/jest.config.ts (2)
apps/deploy-web/next.config.js (4)
require(5-5)require(11-11)require(15-15)path(12-12)packages/logging/src/config/index.ts (1)
Config(7-7)
⏰ 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). (15)
- GitHub Check: validate (apps/log-collector) / validate-unsafe
- GitHub Check: validate (packages) / validate-unsafe
- GitHub Check: validate (apps/provider-console) / validate-unsafe
- GitHub Check: test-build
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: test-build
- GitHub Check: test-build
- GitHub Check: test-build
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: Validate local packages
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (15)
packages/ui/styles/global.css (1)
6-6: The.lightclass selector is not currently used in the codebase.The theme system checks for the presence of the
"dark"class on the document element (classList.contains("dark")), with light mode being the default state when this class is absent. Adding:root, .light {to the CSS assumes that the application applies aclass="light"attribute somewhere, but no such usage exists in the code. The selector will have no effect.Likely an incorrect or invalid review comment.
apps/api/src/notifications/services/notification/notification.service.spec.ts (1)
146-146: LGTM!The updated expectation correctly reflects the reduced retry count in the implementation.
apps/api/src/notifications/services/notification/notification.service.ts (1)
10-10: LGTM!The reduced retry count improves user experience by preventing prolonged hangs during authentication failures. The trade-off between failure speed and resilience is appropriate for login flows.
apps/deploy-web/src/hooks/useLoginRequiredEventHandler.tsx (1)
34-36: LGTM!The update to use
loginViaOauth()aligns with the API rename across the codebase. TheauthServicedependency is correctly included in the callback's closure via the outeruseCallback.apps/deploy-web/src/components/onboarding/OnboardingContainer/OnboardingContainer.tsx (1)
174-177: LGTM!The migration from
signuptologinViaOauthis consistent with the broader API refactor. ThereturnToURL construction correctly preserves the origin and onboarding path, andauthServiceis properly listed in the dependency array.apps/deploy-web/src/services/app-di-container/server-di-container.service.ts (2)
35-49: LGTM!The
SessionServiceis properly wired with:
externalApiHttpClientfor OAuth provider calls- A dedicated console API client with interceptors applied
- Auth0 configuration including secrets (appropriate for server-side)
The separation between
externalApiHttpClientand the console-specific client is a clean design for different API targets.
31-31: Dynamic base URL resolution is an improvementSwitching from a potentially hardcoded URL to
apiUrlService.getBaseApiUrlFor()centralizes URL management and supports multi-network configurations.apps/deploy-web/src/pages/api/auth/password-signup.ts (2)
6-9: LGTM! Unicode property escapes provide robust international character support.The password validation regex patterns use Unicode property escapes (
\p{Ll},\p{Lu},\p{Nd}) which correctly handle international characters beyond ASCII. This is a best practice for global applications.
36-49: Password signup flow is correctly implemented.The handler properly validates input, calls the session service, sets the session on success, and returns appropriate HTTP status codes (204 for success, 400 for client errors).
apps/deploy-web/src/pages/api/auth/password-login.ts (1)
6-28: LGTM! Password login implementation follows consistent patterns.The handler correctly validates credentials, calls the session service, and handles success/error cases with appropriate HTTP status codes. The implementation is consistent with the password-signup endpoint.
apps/deploy-web/src/lib/auth0/setSession/setSession.ts (1)
1-14: Acknowledged workaround with clear documentation.The comprehensive comments clearly explain this is a temporary solution until Auth0 officially supports session creation from API responses. The documented approach (webpack aliases, Jest config, module patching) provides maintainability context for future developers.
apps/deploy-web/src/services/auth/auth/auth.service.ts (2)
15-30: LGTM! OAuth login method properly supports connection parameter.The renamed
loginViaOauthmethod correctly adds the optionalconnectionparameter to query params when provided, maintaining backward compatibility with existing callers.
32-45: Password authentication methods are correctly implemented.Both
loginandsignupmethods properly POST credentials to their respective API endpoints. Thesignupmethod correctly includes thetermsAndConditionsfield for compliance validation.apps/deploy-web/jest.config.ts (2)
2-4: ESM-friendlyrequireusage looks correctUsing
createRequire(import.meta.url)plus a typedrequire.resolvefor path discovery is an appropriate way to keep this Jest config in ESM/TS while still leveraging Node resolution. No issues here.If you haven’t already, please run the Jest suite once from a clean checkout to confirm the config file loads correctly under your current Node/Jest TS loader setup.
Also applies to: 10-10
30-30: Multi-project Jest config and Auth0 transforms look consistent
- Excluding
/lib/nextjs/and/lib/auth0/from the jsdom project and then explicitly targetingsrc/lib/{nextjs,auth0}in theunit-nodeproject keeps responsibilities clear between browser- and node-focused tests.- Adding
/lib/auth0/tocoveragePathIgnorePatternsfor theunitproject plus the more granular ignore rules forunit-nodelooks deliberate and consistent.- The
unit-nodetransformIgnorePatternsand extratransformentry for@auth0/nextjs-auth0/...\.jsusingts-jestwithtsconfig.build.jsonis a reasonable way to selectively transpile that ESM dependency without touching the rest ofnode_modules.Overall this block hangs together and respects the existing
commonconfig.Please confirm that:
- Node tests under
src/lib/{nextjs,auth0}are discovered with thistestMatchglob on your platform, andtsconfig.build.jsonis compatible with transforming the@auth0/nextjs-auth0JavaScript files (e.g.,allowJsor equivalent where needed).Also applies to: 46-46, 54-67
2 participants
Why
#2332
Summary by CodeRabbit
New Features
Bug Fixes
Tests
Chores
Style
✏️ Tip: You can customize this high-level summary in your review settings.