Fix: "Login as Vigy" button 404 error - Add dedicated Vigy login page#2704
Fix: "Login as Vigy" button 404 error - Add dedicated Vigy login page#27041234-ad wants to merge 2 commits intocodervivek5:mainfrom
Conversation
- Add dedicated login page for Vigy (seller) users - Implement email/password authentication - Add remember me functionality - Include password visibility toggle - Add loading state with spinner - Provide links to registration and user login - Match design system with existing auth pages - Add proper error handling with SweetAlert2 - Store user type in localStorage for role management Addresses codervivek5#2638
- Import VigyLogin component - Add route for /vigy-login pointing to VigyLogin component - Remove old route that pointed to VigyForm (registration) - Separate login and registration flows for Vigy users - Add comment clarifying Vigy (Seller) login page route Fixes codervivek5#2638
|
@1234-ad is attempting to deploy a commit to the Vivek Prajapati's projects Team on Vercel. A member of the Team first needs to authorize it. |
📝 WalkthroughWalkthroughThis change replaces the VigyForm component with a new VigyLogin component for the vigy-login route in App.jsx. The new component provides seller login functionality with email/password fields, password visibility toggle, remember-me option, and integrates with an API endpoint for authentication. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
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 |
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Fix all issues with AI agents
In @src/User/pages/VigyLogin/VigyLogin.jsx:
- Line 16: The rememberMe state (rememberMe / setRememberMe) is declared but
never used; either remove the checkbox/state or wire it into the login flow: in
the login submission handler (e.g., handleSubmit / handleLogin where you call
the auth API), include the rememberMe value and when authentication succeeds
persist the returned token accordingly—if rememberMe is true store the token in
localStorage (or set a long-lived cookie) else store it in sessionStorage (or a
short-lived cookie); also ensure the checkbox input is bound to
rememberMe/setRememberMe so its value is captured and remove the unused state
entirely if you opt not to support this feature.
- Around line 27-29: The current conditional only sets localStorage when role
!== undefined which can leave a stale role from prior sessions if the backend
returns null; update the logic around role handling in VigyLogin.jsx so that
when role === undefined you call localStorage.removeItem("role"), otherwise
persist the current value with localStorage.setItem("role", String(role)) (refer
to the existing role variable and localStorage.setItem/removeItem calls in the
file).
- Around line 51-54: The axios.post call to `${apiUrl}/auth/vigy-login` in
VigyLogin.jsx is calling a non-existent backend endpoint; change the request to
use the existing `/auth/login` endpoint (i.e., update the axios.post in
VigyLogin.jsx that sends { email: loginEmail, password: loginPassword } to
`${apiUrl}/auth/login`) so the frontend matches the backend contract that
returns { message, accessToken, refreshToken, username, role }, or alternatively
implement a new backend route `/auth/vigy-login` that delegates to the existing
login logic and returns the same response shape.
- Line 39: Replace the full-page reload: remove the window.location.reload()
call after navigate() in the login success flow (e.g., in the function handling
form submit / onLoginSuccess) and instead update shared auth state so the Navbar
reacts; call your AuthContext method (e.g., authContext.setUser(...) or
authContext.refreshAuth()) or dispatch a global auth event after successful
login, then use navigate(...) for SPA routing so the UI updates without a full
page reload.
- Around line 23-26: The frontend is calling a non-existent /auth/vigy-login and
storing sensitive tokens in localStorage; remove the localStorage.setItem calls
in VigyLogin.jsx (accessToken/username/isLoggedIn/userType) and instead call the
existing /auth/login endpoint; update the backend login handler in
backend/routes/authRoutes.js (the /login route) to set the access token as a
secure, httpOnly cookie (same pattern as the Google OAuth callback:
res.cookie(name, token, { httpOnly: true, secure: true, sameSite: 'lax', maxAge:
... }) and return only non-sensitive user info), and adjust VigyLogin.jsx to
rely on the cookie-based session (use a follow-up API call to fetch user profile
or status) and mark user type in app state rather than storing tokens
client-side.
🧹 Nitpick comments (1)
src/User/pages/VigyLogin/VigyLogin.jsx (1)
114-121: Accessibility: Add aria-labels to form inputs for screen readers.The email and password inputs lack aria-labels, which can make the form difficult to navigate for users relying on assistive technologies. While the placeholder text provides visual context, explicit labels improve accessibility.
♿ Proposed accessibility improvements
<input type="email" placeholder="Email" + aria-label="Email address" className="..." value={loginEmail} onChange={(e) => setLoginEmail(e.target.value)} required /> <input type={showLoginPassword ? "text" : "password"} placeholder="Password" + aria-label="Password" className="..." value={loginPassword} onChange={(e) => setLoginPassword(e.target.value)} required />Also applies to: 125-132
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/App.jsxsrc/User/pages/VigyLogin/VigyLogin.jsx
🧰 Additional context used
🧬 Code graph analysis (2)
src/App.jsx (1)
src/User/pages/VigyLogin/VigyLogin.jsx (1)
VigyLogin(9-223)
src/User/pages/VigyLogin/VigyLogin.jsx (2)
src/Admin/Pages/AdminPanel.jsx (1)
data(16-16)backend/controllers/authController.js (1)
role(173-173)
🔇 Additional comments (4)
src/User/pages/VigyLogin/VigyLogin.jsx (2)
133-139: Good implementation of password visibility toggle.The password show/hide functionality is well-implemented with proper state management and visual feedback using FaEye/FaEyeSlash icons.
57-63: Good error handling with fallback message.The error handling properly uses optional chaining to safely access nested error properties and provides a user-friendly fallback message when the API doesn't return a specific error message.
src/App.jsx (2)
51-51: LGTM: Import statement correctly references the new component.The import path for VigyLogin is correct and follows the project's file structure conventions.
186-187: LGTM: Route update fixes the 404 error as intended.The route now correctly maps
/vigy-loginto the VigyLogin component instead of VigyForm, which resolves the issue where the "Login as Vigy" button was showing a registration form. The comment clearly documents this is the seller login route, and VigyForm is appropriately retained at/admin/vigy-formfor registration purposes (line 215).
| // Login state | ||
| const [loginEmail, setLoginEmail] = useState(""); | ||
| const [loginPassword, setLoginPassword] = useState(""); | ||
| const [rememberMe, setRememberMe] = useState(false); |
There was a problem hiding this comment.
Minor: rememberMe state is captured but never used.
The rememberMe checkbox state is collected but not sent to the API endpoint or used to persist credentials. If "remember me" functionality is intended, implement token persistence logic; otherwise, consider removing this unused feature to avoid user confusion.
Would you like me to suggest an implementation for "remember me" functionality using token expiration or persistent storage?
Also applies to: 43-67
🤖 Prompt for AI Agents
In @src/User/pages/VigyLogin/VigyLogin.jsx at line 16, The rememberMe state
(rememberMe / setRememberMe) is declared but never used; either remove the
checkbox/state or wire it into the login flow: in the login submission handler
(e.g., handleSubmit / handleLogin where you call the auth API), include the
rememberMe value and when authentication succeeds persist the returned token
accordingly—if rememberMe is true store the token in localStorage (or set a
long-lived cookie) else store it in sessionStorage (or a short-lived cookie);
also ensure the checkbox input is bound to rememberMe/setRememberMe so its value
is captured and remove the unused state entirely if you opt not to support this
feature.
| localStorage.setItem("accessToken", accessToken); | ||
| localStorage.setItem("username", username); | ||
| localStorage.setItem("isLoggedIn", "true"); | ||
| localStorage.setItem("userType", "vigy"); // Mark as Vigy user |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Explore repository structure
echo "=== Repository structure ==="
git ls-files | head -30Repository: codervivek5/VigyBag
Length of output: 890
🏁 Script executed:
#!/bin/bash
# Look at the VigyLogin.jsx file in context
echo "=== VigyLogin.jsx file (first 50 lines) ==="
cat -n src/User/pages/VigyLogin/VigyLogin.jsx | head -50Repository: codervivek5/VigyBag
Length of output: 2155
🏁 Script executed:
#!/bin/bash
# Search for backend cookie-based authentication patterns
echo "=== Searching for httpOnly/cookie patterns in backend ==="
find . -type f \( -name "*.js" -o -name "*.jsx" -o -name "*.ts" -o -name "*.tsx" \) -path "*/backend/*" -o -path "*/server/*" | head -20Repository: codervivek5/VigyBag
Length of output: 742
🏁 Script executed:
#!/bin/bash
# Search for localStorage usage across codebase to see if it's widespread
echo "=== localStorage usage across codebase ==="
rg "localStorage\.(setItem|getItem)" -n --type=js --type=jsx | head -20Repository: codervivek5/VigyBag
Length of output: 150
🏁 Script executed:
#!/bin/bash
# Check for token handling patterns - both cookie and storage based
echo "=== Token handling patterns ==="
rg "accessToken|authToken|token.*cookie" -n -B2 -A2 --type=js --type=jsx | head -40Repository: codervivek5/VigyBag
Length of output: 139
🏁 Script executed:
#!/bin/bash
# Check authController.js for token handling and cookie setup
echo "=== authController.js ==="
cat -n backend/controllers/authController.js | head -80Repository: codervivek5/VigyBag
Length of output: 3470
🏁 Script executed:
#!/bin/bash
# Check app.js for middleware configuration
echo "=== backend/app.js ==="
cat -n backend/app.jsRepository: codervivek5/VigyBag
Length of output: 2354
🏁 Script executed:
#!/bin/bash
# Search for localStorage and cookie patterns using better approach
echo "=== Searching for localStorage usage ==="
find . -name "*.js" -o -name "*.jsx" | xargs grep -l "localStorage" 2>/dev/null | head -15Repository: codervivek5/VigyBag
Length of output: 680
🏁 Script executed:
#!/bin/bash
# Search for cookie-related patterns in backend
echo "=== Searching for cookie patterns in backend ==="
grep -r "cookie\|httpOnly\|res\.cookie" backend/ --include="*.js" -n | head -30Repository: codervivek5/VigyBag
Length of output: 422
🏁 Script executed:
#!/bin/bash
# Check axios setup for token handling
echo "=== Searching for axios interceptors and token headers ==="
grep -r "Authorization\|axios.*defaults\|interceptor" src/ --include="*.jsx" --include="*.js" -n | head -20Repository: codervivek5/VigyBag
Length of output: 121
🏁 Script executed:
#!/bin/bash
# Examine authRoutes.js login endpoint around the cookie setting
echo "=== authRoutes.js around cookie setup ==="
cat -n backend/routes/authRoutes.js | head -100Repository: codervivek5/VigyBag
Length of output: 2595
🏁 Script executed:
#!/bin/bash
# Check if there's any verification middleware protecting the token
echo "=== Checking for token verification middleware ==="
grep -r "Authorization\|verifyToken\|authenticate" backend/middlewares/ --include="*.js" -n | head -20Repository: codervivek5/VigyBag
Length of output: 113
🏁 Script executed:
#!/bin/bash
# See the full login endpoint response structure
echo "=== Full login endpoint in authRoutes.js ==="
cat -n backend/routes/authRoutes.js | sed -n '1,100p'Repository: codervivek5/VigyBag
Length of output: 2598
🏁 Script executed:
#!/bin/bash
# Check if frontend axios has any default setup for cookies
echo "=== Check main.jsx or app initialization ==="
find src -name "main.jsx" -o -name "App.jsx" -o -name "index.jsx" | xargs cat -n 2>/dev/null | head -50Repository: codervivek5/VigyBag
Length of output: 2591
🏁 Script executed:
#!/bin/bash
# Look at how tokens are used in protected routes/components
echo "=== Check PrivateRoute.jsx ==="
cat -n src/PrivateRoute.jsxRepository: codervivek5/VigyBag
Length of output: 427
🏁 Script executed:
#!/bin/bash
# Check the standard login endpoint in authController.js
echo "=== authController.login endpoint ==="
cat -n backend/controllers/authController.js | sed -n '140,250p'Repository: codervivek5/VigyBag
Length of output: 4898
🏁 Script executed:
#!/bin/bash
# Search for the login function signature
echo "=== Finding login export in authController ==="
grep -n "exports.login\|\.login\s*=" backend/controllers/authController.jsRepository: codervivek5/VigyBag
Length of output: 151
🏁 Script executed:
#!/bin/bash
# Get a broader view of authController to find login function
echo "=== authController.js lines 200-300 ==="
cat -n backend/controllers/authController.js | sed -n '200,300p'Repository: codervivek5/VigyBag
Length of output: 4450
🏁 Script executed:
#!/bin/bash
# Check how the frontend uses the accessToken from localStorage
echo "=== How is accessToken used in requests ==="
grep -r "localStorage.getItem.*accessToken\|headers.*Authorization" src/ --include="*.jsx" --include="*.js" -B2 -A2 | head -40Repository: codervivek5/VigyBag
Length of output: 106
🏁 Script executed:
#!/bin/bash
# Check the VigyLogin.jsx handleLogin function to see the API call
echo "=== VigyLogin.jsx handleLogin function ==="
cat -n src/User/pages/VigyLogin/VigyLogin.jsx | sed -n '43,75p'Repository: codervivek5/VigyBag
Length of output: 1580
🏁 Script executed:
#!/bin/bash
# See the full login response handling in VigyLogin
echo "=== VigyLogin.jsx complete handleLogin and handleLoginSuccess ==="
cat -n src/User/pages/VigyLogin/VigyLogin.jsx | sed -n '43,90p'Repository: codervivek5/VigyBag
Length of output: 2317
🏁 Script executed:
#!/bin/bash
# Check if axios is configured with withCredentials
echo "=== Check axios configuration ==="
find src -name "*.jsx" -o -name "*.js" | xargs grep -l "axios\|interceptor" | head -10Repository: codervivek5/VigyBag
Length of output: 500
🏁 Script executed:
#!/bin/bash
# Check if there's an axios instance setup file
echo "=== Looking for api/axios configuration ==="
find src -type f \( -name "*api*" -o -name "*axios*" \) | head -10Repository: codervivek5/VigyBag
Length of output: 106
🏁 Script executed:
#!/bin/bash
# Check what the /auth/vigy-login backend endpoint does (from authController)
echo "=== Check if vigy-login endpoint sets cookies ==="
grep -n "vigy-login\|vigy" backend/routes/authRoutes.jsRepository: codervivek5/VigyBag
Length of output: 267
🏁 Script executed:
#!/bin/bash
# Search for vigy-login handler in authController
echo "=== Search authController for vigy-login handler ==="
grep -n "vigy\|exports\." backend/controllers/authController.js | head -20Repository: codervivek5/VigyBag
Length of output: 285
🏁 Script executed:
#!/bin/bash
# Check if vigy-login is actually an alias for login or a separate endpoint
echo "=== Check authRoutes.js for all POST /auth endpoints ==="
grep -n "router.post" backend/routes/authRoutes.jsRepository: codervivek5/VigyBag
Length of output: 323
🏁 Script executed:
#!/bin/bash
# Search the entire backend for vigy-login handler
echo "=== Search entire backend for vigy-login ==="
grep -r "vigy-login" backend/ --include="*.js" -nRepository: codervivek5/VigyBag
Length of output: 107
🏁 Script executed:
#!/bin/bash
# Check if there's middleware that adds cookies for other endpoints
echo "=== Check if standard /auth/login sets cookies ==="
grep -A20 "exports.login" backend/controllers/authController.js | grep -i "cookie\|httpOnly"Repository: codervivek5/VigyBag
Length of output: 113
🏁 Script executed:
#!/bin/bash
# Check if there's another auth route file or if vigy-login is defined elsewhere
echo "=== Search all backend routes ==="
find backend/routes -name "*.js" -exec grep -l "vigy\|login" {} \;Repository: codervivek5/VigyBag
Length of output: 167
🏁 Script executed:
#!/bin/bash
# List all route files in backend
echo "=== All backend route files ==="
ls -la backend/routes/Repository: codervivek5/VigyBag
Length of output: 795
🏁 Script executed:
#!/bin/bash
# Check index.js in routes which might aggregate routes
echo "=== backend/routes/index.js ==="
cat -n backend/routes/index.jsRepository: codervivek5/VigyBag
Length of output: 553
🏁 Script executed:
#!/bin/bash
# Let's see what's being imported in app.js to understand the routing
echo "=== Full backend/app.js ==="
cat -n backend/app.jsRepository: codervivek5/VigyBag
Length of output: 2359
🏁 Script executed:
#!/bin/bash
# Check if vigy-login might be a typo and it should be /auth/login
echo "=== Check VigyForm.jsx (admin registration) to see how IT handles login ==="
grep -n "login\|axios.post" src/Admin/Pages/VigyForm.jsx | head -20Repository: codervivek5/VigyBag
Length of output: 240
🏁 Script executed:
#!/bin/bash
# Check AdminLogin.jsx to see its approach
echo "=== Check AdminLogin.jsx ==="
head -100 src/Admin/Pages/AdminLogin.jsxRepository: codervivek5/VigyBag
Length of output: 2972
🏁 Script executed:
#!/bin/bash
# Check if vigy-login is perhaps created dynamically or if it's a missing endpoint
echo "=== Check if /auth/vigy-login returns 404 ==="
grep -r "vigy-login" src/ --include="*.jsx" --include="*.js" -nRepository: codervivek5/VigyBag
Length of output: 371
🏁 Script executed:
#!/bin/bash
# Check UserAuth.jsx to see if there are other login flows
echo "=== Check UserAuth.jsx to see login patterns ==="
cat -n src/User/pages/UserAuth/UserAuth.jsx | head -80Repository: codervivek5/VigyBag
Length of output: 3262
🏁 Script executed:
#!/bin/bash
# Look for error handling in VigyLogin that might catch 404s
echo "=== Check VigyLogin.jsx error handling and full file ==="
wc -l src/User/pages/VigyLogin/VigyLogin.jsxRepository: codervivek5/VigyBag
Length of output: 162
🏁 Script executed:
#!/bin/bash
# Check what the backend actually returns from /auth/login
echo "=== Review the login handler return (lines 183-194 of authController) ==="
cat -n backend/controllers/authController.js | sed -n '183,194p'Repository: codervivek5/VigyBag
Length of output: 644
🏁 Script executed:
#!/bin/bash
# Check if there's a dedicated vigy-login handler we haven't found yet
echo "=== Search entire codebase for vigy-login definition ==="
grep -r "vigy-login\|vigy.login" . --include="*.js" --include="*.jsx" -B2 -A2 2>/dev/null | grep -v node_modules | head -30Repository: codervivek5/VigyBag
Length of output: 1268
🏁 Script executed:
#!/bin/bash
# Let's check if the login endpoint actually sets cookies anywhere
echo "=== Check if /auth/login in authRoutes/Controller sets any cookies ==="
grep -B5 -A15 "exports.login" backend/controllers/authController.js | grep -i "cookie\|res\."Repository: codervivek5/VigyBag
Length of output: 295
🏁 Script executed:
#!/bin/bash
# Check the complete VigyLogin.jsx to understand the full flow
echo "=== Complete VigyLogin.jsx file ==="
cat src/User/pages/VigyLogin/VigyLogin.jsxRepository: codervivek5/VigyBag
Length of output: 8819
The endpoint /auth/vigy-login doesn't exist in the backend, and storing sensitive tokens in localStorage is a security risk.
The VigyLogin component calls /auth/vigy-login (line 51), but this endpoint is not defined in backend/routes/authRoutes.js—only /signup, /login, /send-otp, and /verify-otp are available. The request will fail.
Additionally, storing the accessToken in localStorage (lines 23–26) exposes it to XSS attacks. The backend already demonstrates the correct approach in the Google OAuth callback (backend/routes/authRoutes.js, lines 50–56), which sets a secure httpOnly cookie. Apply the same pattern to the standard login: modify the /auth/login endpoint to set an httpOnly cookie instead of returning the token in the JSON response, and remove the localStorage storage from the frontend.
🤖 Prompt for AI Agents
In @src/User/pages/VigyLogin/VigyLogin.jsx around lines 23 - 26, The frontend is
calling a non-existent /auth/vigy-login and storing sensitive tokens in
localStorage; remove the localStorage.setItem calls in VigyLogin.jsx
(accessToken/username/isLoggedIn/userType) and instead call the existing
/auth/login endpoint; update the backend login handler in
backend/routes/authRoutes.js (the /login route) to set the access token as a
secure, httpOnly cookie (same pattern as the Google OAuth callback:
res.cookie(name, token, { httpOnly: true, secure: true, sameSite: 'lax', maxAge:
... }) and return only non-sensitive user info), and adjust VigyLogin.jsx to
rely on the cookie-based session (use a follow-up API call to fetch user profile
or status) and mark user type in app state rather than storing tokens
client-side.
| if (role !== undefined) { | ||
| localStorage.setItem("role", role); | ||
| } |
There was a problem hiding this comment.
Potential issue: Conditional role storage may cause inconsistencies.
Storing role only when it's not undefined means:
- If the backend returns
role: null, it won't be stored, but previous role values may persist in localStorage - This can cause stale role data to remain from previous logins
Consider always storing role (even if null) or explicitly removing it when undefined:
🔧 Proposed fix
localStorage.setItem("username", username);
localStorage.setItem("isLoggedIn", "true");
localStorage.setItem("userType", "vigy");
- if (role !== undefined) {
- localStorage.setItem("role", role);
- }
+ if (role !== undefined && role !== null) {
+ localStorage.setItem("role", role);
+ } else {
+ localStorage.removeItem("role");
+ }🤖 Prompt for AI Agents
In @src/User/pages/VigyLogin/VigyLogin.jsx around lines 27 - 29, The current
conditional only sets localStorage when role !== undefined which can leave a
stale role from prior sessions if the backend returns null; update the logic
around role handling in VigyLogin.jsx so that when role === undefined you call
localStorage.removeItem("role"), otherwise persist the current value with
localStorage.setItem("role", String(role)) (refer to the existing role variable
and localStorage.setItem/removeItem calls in the file).
| showConfirmButton: false, | ||
| }).then(() => { | ||
| navigate("/dashboard"); // Redirect to dashboard | ||
| window.location.reload(); // Reload to update Navbar |
There was a problem hiding this comment.
Critical: window.location.reload() defeats SPA navigation and creates poor UX.
Calling window.location.reload() after navigate() forces a full page reload, which:
- Negates the benefits of client-side routing
- Causes a jarring user experience with a visible page refresh
- Re-downloads all assets unnecessarily
- Loses any in-memory application state
Instead, implement proper state management (e.g., Context API, Redux) to update the Navbar reactively when login state changes.
♻️ Recommended approach using Context
Instead of reloading, emit an event or update shared auth context:
}).then(() => {
navigate("/dashboard");
- window.location.reload(); // Reload to update Navbar
});Ensure your AuthContext (imported in App.jsx) exposes a method to refresh auth state, then call it here.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In @src/User/pages/VigyLogin/VigyLogin.jsx at line 39, Replace the full-page
reload: remove the window.location.reload() call after navigate() in the login
success flow (e.g., in the function handling form submit / onLoginSuccess) and
instead update shared auth state so the Navbar reacts; call your AuthContext
method (e.g., authContext.setUser(...) or authContext.refreshAuth()) or dispatch
a global auth event after successful login, then use navigate(...) for SPA
routing so the UI updates without a full page reload.
| const response = await axios.post(`${apiUrl}/auth/vigy-login`, { | ||
| email: loginEmail, | ||
| password: loginPassword, | ||
| }); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for the vigy-login endpoint definition in backend routes
find . -type f \( -name "*.js" -o -name "*.ts" -o -name "*.jsx" -o -name "*.tsx" \) | xargs rg -l "vigy-login|vigyLogin" 2>/dev/null | head -20Repository: codervivek5/VigyBag
Length of output: 156
🏁 Script executed:
#!/bin/bash
# More comprehensive search for auth routes and vigy-login endpoint
rg -n "vigy-login|vigyLogin" --type=js --type=ts -C 10 2>/dev/null | head -100Repository: codervivek5/VigyBag
Length of output: 4723
🏁 Script executed:
#!/bin/bash
# Search for backend auth route files
find . -path ./node_modules -prune -o -type f \( -name "*auth*" -o -name "*route*" \) -print | grep -E "\.(js|ts)$" | head -20Repository: codervivek5/VigyBag
Length of output: 156
🏁 Script executed:
cat -n ./backend/routes/authRoutes.jsRepository: codervivek5/VigyBag
Length of output: 2553
🏁 Script executed:
cat -n ./backend/controllers/authController.jsRepository: codervivek5/VigyBag
Length of output: 13160
Backend endpoint /auth/vigy-login does not exist.
The frontend code at lines 51-54 calls a non-existent endpoint. The backend defines only these auth routes:
/signup/login/send-otp/verify-otp
The backend /login endpoint (which handles both user and admin logins) returns { message, accessToken, refreshToken, username, role }, matching the contract structure expected by the frontend. Either:
- Update the frontend to call
/auth/logininstead of/auth/vigy-login, or - Create a new
/auth/vigy-loginendpoint in the backend that wraps or delegates to the existing login logic.
🤖 Prompt for AI Agents
In @src/User/pages/VigyLogin/VigyLogin.jsx around lines 51 - 54, The axios.post
call to `${apiUrl}/auth/vigy-login` in VigyLogin.jsx is calling a non-existent
backend endpoint; change the request to use the existing `/auth/login` endpoint
(i.e., update the axios.post in VigyLogin.jsx that sends { email: loginEmail,
password: loginPassword } to `${apiUrl}/auth/login`) so the frontend matches the
backend contract that returns { message, accessToken, refreshToken, username,
role }, or alternatively implement a new backend route `/auth/vigy-login` that
delegates to the existing login logic and returns the same response shape.
Description
This PR fixes the 404 error that occurs when clicking the "Login as Vigy" button on the authentication page, addressing issue #2638.
Problem Statement
When users click the "Login as Vigy" button on the VigyBag landing/auth page, they are redirected to a 404 error page. This happens because:
/vigy-loginrouteVigyFormcomponent (which is a registration form, not a login form)Root Cause Analysis
Issue Flow:
UserAuth.jsx(line 367-372)/vigy-loginrouteVigyFormcomponent (a registration form)Code Evidence:
UserAuth.jsx (line 367-372):
App.jsx (old - line 186):
The
VigyFormcomponent is actually a seller registration form with multiple tabs (Personal, Contact, Banking, Verification, Additional), not a login form.Solution Implemented
1. Created Dedicated VigyLogin Component
File:
src/User/pages/VigyLogin/VigyLogin.jsxA complete login page specifically for Vigy (seller) users with:
Key Features:
2. Updated App.jsx Routing
Changes:
VigyLogincomponent/vigy-loginroute to point toVigyLogininstead ofVigyForm{/* Vigy (Seller) login page route */}VigyFormfor registration at/admin/vigy-formBefore:
After:
3. Clear Separation of Concerns
/vigy-login→VigyLogincomponent/admin/vigy-form→VigyFormcomponent/auth→UserAuthcomponent/admin-verification→AdminVerificationPagecomponentUser Flow (After Fix)
Vigy Login Flow:
/vigy-login/auth/vigy-loginVigy Registration Flow:
/admin/vigy-formBenefits
✅ No More 404 Error: Proper route with dedicated component
✅ Clear User Intent: Login button leads to login page
✅ Better UX: Separate login and registration flows
✅ Consistent Design: Matches existing auth page styling
✅ Role Management: Tracks user type in localStorage
✅ Responsive: Works on mobile and desktop
✅ Error Handling: Proper feedback for failed logins
✅ Navigation: Clear links between login/registration/user auth
Testing Checklist
Screenshots
Before (404 Error):
After (Working Login Page):
Technical Details
Component Structure:
API Integration:
State Management:
Related Issue
Closes #2638
Additional Notes
/auth/vigy-loginendpoint if it doesn't exist yetFuture Enhancements (Optional)
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.