fix: implement server-side auth API calls in signin/signup pages#38
Open
OkiriGabriel wants to merge 1 commit into
Open
fix: implement server-side auth API calls in signin/signup pages#38OkiriGabriel wants to merge 1 commit into
OkiriGabriel wants to merge 1 commit into
Conversation
Replace client-side-only stub (fake timeout + hardcoded email check) with real fetch calls to the backend auth endpoints in both DevOps-Project-39 and DevOps-Project-40. - POST /api/auth/email-password/signup for registration - POST /api/auth/email-password/signin for login - Map frontend `username` field to backend `name` field - Show backend error messages via toast on failure - Navigate to home only on successful response - Use existing VITE_API_PATH env var (consistent with other pages) Resolves TODO: Server-side validation comments in both projects Co-authored-by: Cursor <cursoragent@cursor.com>
📝 WalkthroughWalkthroughSignin and signup forms in two frontend project copies now call backend email/password endpoints with JSON payloads, handle response status with toast messages, reset on success, navigate to ChangesWanderlust frontend auth submissions
Mega project frontend auth submissions
Sequence Diagram(s)Signin flow sequenceDiagram
participant User
participant SigninPage as signin-page.tsx
participant AuthAPI as POST /api/auth/email-password/signin
participant Toast as toast
participant Router as navigate('/')
User->>SigninPage: Submit email and password
SigninPage->>AuthAPI: POST JSON body with credentials: include
AuthAPI-->>SigninPage: JSON response
alt response.ok false
SigninPage->>Toast: toast.error(message)
else response.ok true
SigninPage->>Toast: toast.success(...)
SigninPage->>Router: reset() and navigate('/')
end
Note over SigninPage,Toast: catch shows connection error toast
Signup flow sequenceDiagram
participant User
participant SignupPage as signup-page.tsx
participant AuthAPI as POST /api/auth/email-password/signup
participant Toast as toast
participant Router as navigate('/')
User->>SignupPage: Submit username, email, and password
SignupPage->>AuthAPI: POST JSON body with credentials: include
AuthAPI-->>SignupPage: JSON response
alt response.ok false
SignupPage->>Toast: toast.error(result.message or generic message)
else response.ok true
SignupPage->>Toast: toast.success(...)
SignupPage->>Router: reset() and navigate('/')
end
Note over SignupPage,Toast: catch shows connection error toast
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![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
🧹 Nitpick comments (2)
DevOps-Project-40/Devops-Mega-Project-Jenkins-ArgoCD-EKS/frontend/src/pages/signup-page.tsx (1)
34-44: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winNon-JSON error responses are misreported as connection failures.
Same issue as the signin page:
response.json()is parsed before theresponse.okcheck inside thetry, so a non-JSON or empty response body throws and triggers the barecatch's "Unable to connect to the server" toast instead of surfacing the actual signup failure. Guard the parse.♻️ Suggested guard
- const result = await response.json(); - if (!response.ok) { - toast.error(result.message ?? 'Sign up failed. Please try again.'); - return; - } - toast.success(result.message ?? 'Account created successfully!'); + const result = await response.json().catch(() => ({})); + if (!response.ok) { + toast.error(result.message ?? 'Sign up failed. Please try again.'); + return; + } + toast.success(result.message ?? 'Account created successfully!');🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@DevOps-Project-40/Devops-Mega-Project-Jenkins-ArgoCD-EKS/frontend/src/pages/signup-page.tsx` around lines 34 - 44, The signup flow in signup-page.tsx is treating non-JSON or empty error responses as connection failures because `response.json()` in the signup handler runs before the `response.ok` check and can throw into the bare `catch`. Update the submit logic in the signup page’s handler to guard or defer parsing so non-OK responses are handled without forcing the generic network toast, and surface the actual API failure message through the existing `toast.error` path.DevOps-Project-40/Devops-Mega-Project-Jenkins-ArgoCD-EKS/frontend/src/pages/signin-page.tsx (1)
33-43: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winNon-JSON error responses are misreported as connection failures.
response.json()is awaited before theresponse.okcheck and inside the sametry. If the endpoint returns a non-JSON body (HTML error page, empty204/304, proxy/gateway error), the parse throws and falls through to the barecatch, showing "Unable to connect to the server" even though the server responded. Guard JSON parsing so the real HTTP status drives the message.♻️ Suggested guard
- const result = await response.json(); - if (!response.ok) { - toast.error(result.message ?? 'Sign in failed. Please check your credentials.'); - return; - } - toast.success(result.message ?? 'Signed in successfully!'); + const result = await response.json().catch(() => ({})); + if (!response.ok) { + toast.error(result.message ?? 'Sign in failed. Please check your credentials.'); + return; + } + toast.success(result.message ?? 'Signed in successfully!');🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@DevOps-Project-40/Devops-Mega-Project-Jenkins-ArgoCD-EKS/frontend/src/pages/signin-page.tsx` around lines 33 - 43, The signin flow in signin-page.tsx is treating any JSON parse failure as a connection issue because response.json() is awaited inside the same try before checking response.ok. Update the signin handler so the HTTP status check in the signin-page submit logic determines success or failure first, and only parse the response body as JSON when it is actually safe/needed; if parsing fails or there is no JSON body, still surface the proper server-side error instead of falling back to the generic network toast. Refer to the signin submit handler, the response.json() call, and the response.ok branch when making the change.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@DevOps-Project-39/wanderlust-3tier-project/frontend/src/pages/signin-page.tsx`:
- Around line 34-36: The signin error handling in signin-page.tsx is exposing
backend-specific messages from result.message, which can reveal whether an email
exists. Update the failure path in the signin submit flow to always show a
single generic message in the toast.error call, and avoid passing through
backend-auth details from the response. If possible, also align the backend
signin response in the corresponding auth endpoint so it returns the same
generic failure text regardless of whether the email or password is wrong.
- Around line 23-24: The auth API URL fallback is unsafe because signin, signup,
and related pages default to localhost even in production. Update the API URL
resolution in signin-page and the same pattern in signup-page, blog-feed,
home-page, details-page, and add-blog so the localhost fallback is used only
when import.meta.env.DEV is true. In non-dev builds, fail closed by surfacing a
clear configuration error instead of attempting requests without a valid
endpoint. Keep the logic centralized around the existing apiUrl setup so the
behavior is consistent across these page components.
In
`@DevOps-Project-39/wanderlust-3tier-project/frontend/src/pages/signup-page.tsx`:
- Around line 23-24: The signup flow in signup-page.tsx currently falls back to
localhost whenever VITE_API_PATH is missing, which should only happen in
development. Update the logic around the apiUrl used by the signup handler so it
uses the localhost default only in dev mode, and in production it should stop
before the fetch and surface a clear user-facing error if the auth API URL is
unset. Use the existing signup-page.tsx handler and the apiUrl / response flow
to locate the change.
---
Nitpick comments:
In
`@DevOps-Project-40/Devops-Mega-Project-Jenkins-ArgoCD-EKS/frontend/src/pages/signin-page.tsx`:
- Around line 33-43: The signin flow in signin-page.tsx is treating any JSON
parse failure as a connection issue because response.json() is awaited inside
the same try before checking response.ok. Update the signin handler so the HTTP
status check in the signin-page submit logic determines success or failure
first, and only parse the response body as JSON when it is actually safe/needed;
if parsing fails or there is no JSON body, still surface the proper server-side
error instead of falling back to the generic network toast. Refer to the signin
submit handler, the response.json() call, and the response.ok branch when making
the change.
In
`@DevOps-Project-40/Devops-Mega-Project-Jenkins-ArgoCD-EKS/frontend/src/pages/signup-page.tsx`:
- Around line 34-44: The signup flow in signup-page.tsx is treating non-JSON or
empty error responses as connection failures because `response.json()` in the
signup handler runs before the `response.ok` check and can throw into the bare
`catch`. Update the submit logic in the signup page’s handler to guard or defer
parsing so non-OK responses are handled without forcing the generic network
toast, and surface the actual API failure message through the existing
`toast.error` path.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: d58af58a-ebf1-48a4-ab41-a9a312fbbecb
📒 Files selected for processing (4)
DevOps-Project-39/wanderlust-3tier-project/frontend/src/pages/signin-page.tsxDevOps-Project-39/wanderlust-3tier-project/frontend/src/pages/signup-page.tsxDevOps-Project-40/Devops-Mega-Project-Jenkins-ArgoCD-EKS/frontend/src/pages/signin-page.tsxDevOps-Project-40/Devops-Mega-Project-Jenkins-ArgoCD-EKS/frontend/src/pages/signup-page.tsx
Comment on lines
+23
to
+24
| const apiUrl = import.meta.env.VITE_API_PATH ?? 'http://localhost:5000'; | ||
| const response = await fetch(`${apiUrl}/api/auth/email-password/signin`, { |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
frontend='DevOps-Project-39/wanderlust-3tier-project/frontend'
rg -n 'VITE_API_PATH|localhost:5000|import\.meta\.env\.(DEV|PROD)' "$frontend"
fd -H '^(\.env.*|vite\.config\..*)$' "$frontend" -x sh -c '
printf "\n--- %s\n" "$1"
rg -n "VITE_API_PATH|localhost:5000|import\.meta\.env\.(DEV|PROD)" "$1" || true
' sh {}Repository: NotHarshhaa/DevOps-Projects
Length of output: 1603
Fail closed when the auth API URL is missing.
The fallback to http://localhost:5000 whenever VITE_API_PATH is unset is unsafe for production. In a production build, this causes the app to attempt posting credentials to a local service on the user's machine or fail unexpectedly. The same insecure fallback pattern is found in signup-page.tsx, blog-feed.tsx, home-page.tsx, details-page.tsx, and add-blog.tsx.
Gate the localhost fallback to dev builds only (import.meta.env.DEV) and fail safely in production by surfacing a configuration error when the endpoint is missing.
Suggested fix
- const apiUrl = import.meta.env.VITE_API_PATH ?? 'http://localhost:5000';
+ const configuredUrl = import.meta.env.VITE_API_PATH?.trim() || (import.meta.env.DEV ? 'http://localhost:5000' : '');
+ if (!configuredUrl) {
+ toast.error('Authentication service endpoint is not configured.');
+ return;
+ }
+ const apiUrl = configuredUrl.replace(/\/+$/, '');
const response = await fetch(`${apiUrl}/api/auth/email-password/signin`, {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const apiUrl = import.meta.env.VITE_API_PATH ?? 'http://localhost:5000'; | |
| const response = await fetch(`${apiUrl}/api/auth/email-password/signin`, { | |
| const configuredUrl = import.meta.env.VITE_API_PATH?.trim() || (import.meta.env.DEV ? 'http://localhost:5000' : ''); | |
| if (!configuredUrl) { | |
| toast.error('Authentication service endpoint is not configured.'); | |
| return; | |
| } | |
| const apiUrl = configuredUrl.replace(/\/+$/, ''); | |
| const response = await fetch(`${apiUrl}/api/auth/email-password/signin`, { |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@DevOps-Project-39/wanderlust-3tier-project/frontend/src/pages/signin-page.tsx`
around lines 23 - 24, The auth API URL fallback is unsafe because signin,
signup, and related pages default to localhost even in production. Update the
API URL resolution in signin-page and the same pattern in signup-page,
blog-feed, home-page, details-page, and add-blog so the localhost fallback is
used only when import.meta.env.DEV is true. In non-dev builds, fail closed by
surfacing a clear configuration error instead of attempting requests without a
valid endpoint. Keep the logic centralized around the existing apiUrl setup so
the behavior is consistent across these page components.
Comment on lines
+34
to
+36
| if (!response.ok) { | ||
| toast.error(result.message ?? 'Sign in failed. Please check your credentials.'); | ||
| return; |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Use a generic signin failure message.
The backend contract shown here returns different messages for “email does not exist” and “invalid password”; Line 35 exposes those directly, enabling account enumeration. Keep signin errors generic on the client, and ideally align the backend response too.
Suggested fix
if (!response.ok) {
- toast.error(result.message ?? 'Sign in failed. Please check your credentials.');
+ toast.error('Invalid email or password.');
return;
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| if (!response.ok) { | |
| toast.error(result.message ?? 'Sign in failed. Please check your credentials.'); | |
| return; | |
| if (!response.ok) { | |
| toast.error('Invalid email or password.'); | |
| return; |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@DevOps-Project-39/wanderlust-3tier-project/frontend/src/pages/signin-page.tsx`
around lines 34 - 36, The signin error handling in signin-page.tsx is exposing
backend-specific messages from result.message, which can reveal whether an email
exists. Update the failure path in the signin submit flow to always show a
single generic message in the toast.error call, and avoid passing through
backend-auth details from the response. If possible, also align the backend
signin response in the corresponding auth endpoint so it returns the same
generic failure text regardless of whether the email or password is wrong.
Comment on lines
+23
to
+24
| const apiUrl = import.meta.env.VITE_API_PATH ?? 'http://localhost:5000'; | ||
| const response = await fetch(`${apiUrl}/api/auth/email-password/signup`, { |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
frontend='DevOps-Project-39/wanderlust-3tier-project/frontend'
rg -n 'VITE_API_PATH|localhost:5000|import\.meta\.env\.(DEV|PROD)' "$frontend"
fd -H '^(\.env.*|vite\.config\..*)$' "$frontend" -x sh -c '
printf "\n--- %s\n" "$1"
rg -n "VITE_API_PATH|localhost:5000|import\.meta\.env\.(DEV|PROD)" "$1" || true
' sh {}Repository: NotHarshhaa/DevOps-Projects
Length of output: 1603
Fail closed when the auth API URL is missing in production
Line 23 in DevOps-Project-39/wanderlust-3tier-project/frontend/src/pages/signup-page.tsx unconditionally falls back to http://localhost:5000 if VITE_API_PATH is missing. In a production build, remote users cannot reach a localhost endpoint, causing failed requests and a poor user experience. Restrict this fallback to development mode only and halt execution with a user-facing error if the API URL is missing in production.
Suggested fix
- const apiUrl = import.meta.env.VITE_API_PATH ?? 'http://localhost:5000';
+ const configuredApiUrl = import.meta.env.VITE_API_PATH?.trim();
+ const apiUrl = configuredApiUrl || (import.meta.env.DEV ? 'http://localhost:5000' : '');
+ if (!apiUrl) {
+ toast.error('Authentication service is not configured.');
+ return;
+ }
const response = await fetch(`${apiUrl}/api/auth/email-password/signup`, {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const apiUrl = import.meta.env.VITE_API_PATH ?? 'http://localhost:5000'; | |
| const response = await fetch(`${apiUrl}/api/auth/email-password/signup`, { | |
| const configuredApiUrl = import.meta.env.VITE_API_PATH?.trim(); | |
| const apiUrl = configuredApiUrl || (import.meta.env.DEV ? 'http://localhost:5000' : ''); | |
| if (!apiUrl) { | |
| toast.error('Authentication service is not configured.'); | |
| return; | |
| } | |
| const response = await fetch(`${apiUrl}/api/auth/email-password/signup`, { |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@DevOps-Project-39/wanderlust-3tier-project/frontend/src/pages/signup-page.tsx`
around lines 23 - 24, The signup flow in signup-page.tsx currently falls back to
localhost whenever VITE_API_PATH is missing, which should only happen in
development. Update the logic around the apiUrl used by the signup handler so it
uses the localhost default only in dev mode, and in production it should stop
before the fetch and surface a clear user-facing error if the auth API URL is
unset. Use the existing signup-page.tsx handler and the apiUrl / response flow
to locate the change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
abc@gamil.comcheck) with realfetchcalls to the backend auth endpoints in both DevOps-Project-39 and DevOps-Project-40usernamefield to the backendnamefield (fixes field name mismatch)VITE_API_PATHenv var — consistent with every other page (home-page,add-blog,blog-feed, etc.)Changes
DevOps-Project-39/.../signup-page.tsx/api/auth/email-password/signupDevOps-Project-39/.../signin-page.tsx/api/auth/email-password/signinDevOps-Project-40/.../signup-page.tsx/api/auth/email-password/signupDevOps-Project-40/.../signin-page.tsx/api/auth/email-password/signinType of change
TODO: Server-side validationin both projects)Checklist
Made with Cursor
Summary by CodeRabbit
New Features
Bug Fixes