Reset password workflows #456

julgmz · 2025-11-26T20:04:50Z

Tested full lifecycle by connecting auth to my local server, was able to reset password as expected

github-actions · 2025-11-26T20:04:58Z

Resolves #453

julgmz · 2025-11-26T20:05:10Z

scripts/clean-app-data.js


 const platform = os.platform()
-let appDataPath
+const appNames = ['Ito-dev', 'Ito-local', 'Ito-prod', 'Ito']


fixing cleanup script to hit all envs

julgmz · 2025-11-26T20:06:00Z

app/components/welcome/contents/SignInContent.tsx

+                  : 'Create account'}
              </button>
            </p>
+            {(!userProvider || userProvider === 'email') && (


this is the page that shows when a user is already signed in and has logged out / timed out. we only show the forgot password here if they are provided via email rather than something like google or apple accounts

coderabbitai · 2025-11-26T20:12:01Z

Walkthrough

Adds a password reset flow end-to-end: a new ResetPassword React component (props: email?, onBack) with email validation, resend countdown, and email-client opener; EmailLoginContent and SignInContent updated to toggle/render the reset UI. Adds an IPC channel auth0-reset-password that forwards requests to the backend. Adds a POST /auth0/reset-password route that calls Auth0's change_password endpoint. Refactors scripts/clean-app-data.js to iterate and remove multiple app environment data directories.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run `@coderabbitai generate docstrings` to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Reset password workflows' clearly and directly summarizes the main change: implementing password reset functionality across multiple components and services.
Description check	✅ Passed	The description is related to the changeset, mentioning testing of password reset functionality with authentication connected to a local server.

✨ Finishing touches

📝 Generate docstrings

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment
Commit unit tests in branch ito-453

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1faa92e and e70a667.

📒 Files selected for processing (1)

server/src/services/auth0.ts (2 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

server/src/services/auth0.ts

⏰ 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). (2)

GitHub Check: Analyze (swift)
GitHub Check: Analyze (rust)

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

❤️ Share

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

coderabbitai

Actionable comments posted: 0

🧹 Nitpick comments (6)

scripts/clean-app-data.js (3)
8-8: Consider making app variant list configurable or shared

Hard‑coding the four app variants works, but this list could drift if new variants are added elsewhere. Consider either:

deriving appNames from a single shared config, or

allowing optional CLI arguments to override/extend this list,

so the cleanup script stays in sync with actual deployments.

10-20: Verify Linux path casing and consider XDG_CONFIG_HOME support

On non‑macOS/Windows platforms, getAppDataPath uses ~/.config/${appName.toLowerCase()} while other branches keep the original casing. If any existing Linux data directories were created with a different case (e.g. Ito-dev), this script will miss them. Either:

confirm that the app’s Linux user data path is indeed lowercase and document that assumption, or

drop .toLowerCase() for symmetry, or

optionally check both variants when cleaning.

Additionally, you may want to honor XDG_CONFIG_HOME when set (falling back to ~/.config) for more standard Linux behavior.

23-30: Add error handling around fs.rmSync to avoid abrupt script failures

If fs.rmSync hits permissions issues or other filesystem errors, the script will currently throw and stop at the first failing app directory. Wrapping the removal in a small try/catch with console.error would make the cleanup more robust while still surfacing failures, for example:
-  if (fs.existsSync(appDataPath)) {
-    fs.rmSync(appDataPath, { recursive: true, force: true })
-    console.log(`✓ Removed app data from: ${appDataPath}`)
-  } else {
-    console.log(`ℹ No app data found at: ${appDataPath}`)
-  }
+  if (fs.existsSync(appDataPath)) {
+    try {
+      fs.rmSync(appDataPath, { recursive: true, force: true })
+      console.log(`✓ Removed app data from: ${appDataPath}`)
+    } catch (err) {
+      console.error(`✗ Failed to remove app data at: ${appDataPath}`, err)
+    }
+  } else {
+    console.log(`ℹ No app data found at: ${appDataPath}`)
+  }
This also keeps you compliant with the “no empty catch” guideline.
server/src/services/auth0.ts (1)
8-11: Strengthen /auth0/reset-password handler (typing, logging, validation).

The overall flow looks solid (env guards, Auth0 call, safe JSON/text parsing), but a few hardening tweaks would help:

Line 219: avoid introducing new any (catch (error: any)). Prefer unknown and narrow when building the message, e.g., error instanceof Error ? error.message : 'Network error'. This keeps you aligned with the “never use any” guideline.

Consider logging the caught error via fastify.log.error before returning 500 so failures are observable from the server side, similar to getManagementToken.

Since connection is taken from the request body, you may want to ignore arbitrary values and/or whitelist known DB connections if this route might ever be called by anything other than your own client.

Example for the catch block:
-    } catch (error: any) {
-      reply
-        .status(500)
-        .send({ success: false, error: error?.message || 'Network error' })
-    }
+    } catch (error: unknown) {
+      fastify.log.error({ error }, '[Auth0] reset-password error')
+      const message =
+        error instanceof Error ? error.message : 'Network error'
+      reply.status(500).send({ success: false, error: message })
+    }
Also applies to: 168-224
app/components/welcome/contents/SignInContent.tsx (1)
22-22: Sign-in integration with ResetPassword is solid; consider passing email through.

The new showResetPassword state, early return, and the conditional “Forgot password” link for email/no-provider cases all line up well with the intended UX, and the 50/50 layout keeps the reset view visually consistent with the main sign-in pane.

As a small cleanup, you could pass the known userEmail into <ResetPassword> here instead of having that component re-read from window.electron?.store, e.g.:
if (showResetPassword) {
  return (
    <ResetPassword
      email={typeof userEmail === 'string' ? userEmail : undefined}
      onBack={() => setShowResetPassword(false)}
    />
  )
}
Not strictly necessary, but it would centralize where the email value comes from and simplify testing.

Also applies to: 124-124, 417-419, 424-425, 463-490, 495-496
app/components/welcome/contents/ResetPassword.tsx (1)
1-225: ResetPassword behavior matches the flow; tighten types and timer lifecycle.

The overall UX and wiring to auth0-reset-password look good (pre-populated email, clear “Check your inbox” state, resend throttling). A couple of implementation details are worth tightening:

Lines 56 & 88: both handlers use catch (e: any). Per the TypeScript guidelines, avoid new any usage. You can switch to unknown and narrow when building the error message:
-    } catch (e: any) {
-      setError(e?.message || 'An error occurred')
+    } catch (e: unknown) {
+      const message =
+        e instanceof Error ? e.message : 'An error occurred'
+      setError(message)
     } finally {
       setIsLoading(false)
     }
(and similarly in handleResend).

Lines 40–52 and 74–84: the countdown logic is duplicated and each call creates its own setInterval that only clears itself when seconds reaches 0. If the component unmounts while a countdown is active (e.g., user navigates back immediately), those intervals will still run briefly and attempt setSeconds, which is best avoided. Consider centralizing the countdown into a useRef + useEffect pair that:

Clears any existing interval before starting a new one.

Cleans up in the effect’s return function on unmount.

Optional UX tweak: handleOpenEmailApp currently uses mailto: with no address; you could pass editableEmail (mailto:${editableEmail}) so the reset email target is prefilled in the mail client.

None of these block the flow, but they’ll make the component more robust and closer to the project’s TypeScript standards. As per coding guidelines, avoiding any is the most important of these.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ec1b3cd and 1faa92e.

📒 Files selected for processing (6)

app/components/welcome/contents/EmailLoginContent.tsx (4 hunks)
app/components/welcome/contents/ResetPassword.tsx (1 hunks)
app/components/welcome/contents/SignInContent.tsx (5 hunks)
lib/window/ipcEvents.ts (1 hunks)
scripts/clean-app-data.js (1 hunks)
server/src/services/auth0.ts (2 hunks)

🧰 Additional context used

📓 Path-based instructions (12)

**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Always prefer console commands over log commands. Use console.log instead of log.info

Files:

scripts/clean-app-data.js
app/components/welcome/contents/ResetPassword.tsx
lib/window/ipcEvents.ts
app/components/welcome/contents/EmailLoginContent.tsx
server/src/services/auth0.ts
app/components/welcome/contents/SignInContent.tsx

**/*.{js,jsx,ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/always.mdc)

Never use empty catch statements

Files:

scripts/clean-app-data.js
app/components/welcome/contents/ResetPassword.tsx
lib/window/ipcEvents.ts
app/components/welcome/contents/EmailLoginContent.tsx
server/src/services/auth0.ts
app/components/welcome/contents/SignInContent.tsx

**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/code-conventions.mdc)

**/*.{ts,tsx}: Follow standard, idiomatic TypeScript coding practices for structure, naming, and types
Avoid adding comments unless they explain complex logic or non-obvious decisions; well-written, self-explanatory code is preferred
Do not add comments that merely restate what the code does
Rely on comprehensive tests to document the behavior and usage of code rather than extensive comments within the code itself
Use kebab-case when naming directories, TypeScript, and other files

**/*.{ts,tsx}: Prefer interfaces over types for object definitions
Use type for unions, intersections, and mapped types
NEVER use any or as any types or coercion
Leverage TypeScript's built-in utility types
Use generics for reusable type patterns
Use PascalCase for type names and interfaces
Use camelCase for variables and functions
Use UPPER_CASE for constants
Use descriptive names with auxiliary verbs (e.g., isLoading, hasError)
Prefix interfaces for React props with 'Props' (e.g., ButtonProps)
Keep type definitions close to where they're used
Export types and interfaces from dedicated type files when shared
Co-locate component props with their components
Use explicit return types for public functions
Use arrow functions for callbacks and methods
Implement proper error handling with custom error types
Use function overloads for complex type scenarios
Prefer async/await over Promises
Prefer function declarations over function expressions
Use readonly for immutable properties
Leverage discriminated unions for type safety
Use type guards for runtime type checking
Implement proper null checking
Avoid type assertions unless necessary
Handle Promise rejections properly

Files:

app/components/welcome/contents/ResetPassword.tsx
lib/window/ipcEvents.ts
app/components/welcome/contents/EmailLoginContent.tsx
server/src/services/auth0.ts
app/components/welcome/contents/SignInContent.tsx

**/*.tsx

📄 CodeRabbit inference engine (.cursor/rules/react.mdc)

**/*.tsx: Use kebab-case for files and directories
Do not use 'use client' or 'use server' statements in React components
Favor named exports for components
Ensure components are modular, reusable, and maintain a clear separation of concerns
Always split React components so there is only ever one per file
Keep logic as low as possible in React components
Implement responsive design with Tailwind CSS using a mobile-first approach

Files:

app/components/welcome/contents/ResetPassword.tsx
app/components/welcome/contents/EmailLoginContent.tsx
app/components/welcome/contents/SignInContent.tsx

app/**/*.{ts,tsx,js,jsx}