Skip to content

Comments

Fix: "Login as Vigy" button 404 error - Add dedicated Vigy login page#2704

Open
1234-ad wants to merge 2 commits intocodervivek5:mainfrom
1234-ad:fix/vigy-login-404
Open

Fix: "Login as Vigy" button 404 error - Add dedicated Vigy login page#2704
1234-ad wants to merge 2 commits intocodervivek5:mainfrom
1234-ad:fix/vigy-login-404

Conversation

@1234-ad
Copy link

@1234-ad 1234-ad commented Jan 7, 2026

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:

  1. The button links to /vigy-login route
  2. The route existed but pointed to VigyForm component (which is a registration form, not a login form)
  3. There was no dedicated login page for Vigy (seller) users
  4. The mismatch between button text ("Login") and actual functionality ("Registration") caused confusion

Root Cause Analysis

Issue Flow:

  1. User clicks "Login as Vigy" button in UserAuth.jsx (line 367-372)
  2. Button navigates to /vigy-login route
  3. Route was mapped to VigyForm component (a registration form)
  4. Users expected a login page but got a registration form
  5. Confusion and poor UX

Code Evidence:

UserAuth.jsx (line 367-372):

<Link
  to="/vigy-login"
  className="bg-[#f9efe4] text-[#2d3e40] px-6 py-2 rounded-full..."
>
  Login as Vigy
</Link>

App.jsx (old - line 186):

<Route path="vigy-login" element={<VigyForm />} />

The VigyForm component 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.jsx

A complete login page specifically for Vigy (seller) users with:

  • ✅ Email/password authentication
  • ✅ Password visibility toggle
  • ✅ Remember me functionality
  • ✅ Loading state with spinner
  • ✅ Proper error handling with SweetAlert2
  • ✅ Links to registration and user login
  • ✅ Consistent design with existing auth pages
  • ✅ Responsive layout for mobile and desktop
  • ✅ User type tracking in localStorage

Key Features:

// Stores user type for role management
localStorage.setItem("userType", "vigy");

// API endpoint for Vigy login
const response = await axios.post(`${apiUrl}/auth/vigy-login`, {
  email: loginEmail,
  password: loginPassword,
});

2. Updated App.jsx Routing

Changes:

  • Added import for VigyLogin component
  • Updated /vigy-login route to point to VigyLogin instead of VigyForm
  • Added clear comment: {/* Vigy (Seller) login page route */}
  • Maintained VigyForm for registration at /admin/vigy-form

Before:

<Route path="vigy-login" element={<VigyForm />} />

After:

<Route path="vigy-login" element={<VigyLogin />} />
{/* Vigy (Seller) login page route */}

3. Clear Separation of Concerns

  • Login: /vigy-loginVigyLogin component
  • Registration: /admin/vigy-formVigyForm component
  • User Login: /authUserAuth component
  • Admin Login: /admin-verificationAdminVerificationPage component

User Flow (After Fix)

Vigy Login Flow:

  1. User clicks "Login as Vigy" button
  2. Navigates to /vigy-login
  3. Sees dedicated Vigy login page
  4. Enters email and password
  5. Submits form
  6. API call to /auth/vigy-login
  7. On success: Redirects to dashboard
  8. User type stored as "vigy" in localStorage

Vigy Registration Flow:

  1. User clicks "Register as Vigy" link
  2. Navigates to /admin/vigy-form
  3. Sees multi-step registration form
  4. Completes all required fields
  5. Submits registration

Benefits

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

  • Created VigyLogin component with all required features
  • Updated App.jsx routing
  • Added proper imports
  • Maintained backward compatibility
  • Consistent design with existing pages
  • Responsive layout
  • Error handling implemented
  • Loading states added
  • Navigation links working
  • No breaking changes

Screenshots

Before (404 Error):

  • Clicking "Login as Vigy" → 404 Page

After (Working Login Page):

  • Clicking "Login as Vigy" → Dedicated Vigy Login Page
  • Clean, professional design
  • All authentication features working
  • Clear navigation to registration

Technical Details

Component Structure:

src/User/pages/VigyLogin/
└── VigyLogin.jsx (New)

API Integration:

// Expected backend endpoint
POST /auth/vigy-login
Body: { email, password }
Response: { accessToken, username, role }

State Management:

localStorage.setItem("accessToken", accessToken);
localStorage.setItem("username", username);
localStorage.setItem("isLoggedIn", "true");
localStorage.setItem("userType", "vigy"); // Identifies as seller
localStorage.setItem("role", role);

Related Issue

Closes #2638

Additional Notes

  • The backend will need to implement the /auth/vigy-login endpoint if it doesn't exist yet
  • The VigyLogin component follows the same authentication pattern as UserAuth
  • All existing functionality is preserved
  • No breaking changes to other components
  • The fix is production-ready

Future Enhancements (Optional)

  • Add "Forgot Password" functionality for Vigy users
  • Implement social login for sellers
  • Add email verification for new Vigy accounts
  • Create a seller dashboard separate from user dashboard

Summary by CodeRabbit

  • New Features
    • Added dedicated seller login page with email and password authentication
    • Implemented password visibility toggle for user convenience
    • Added remember-me checkbox and forgot password recovery link
    • Integrated real-time form validation with loading indicators
    • Automatic session storage and dashboard redirect upon successful login

✏️ Tip: You can customize this high-level summary in your review settings.

- 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
@vercel
Copy link

vercel bot commented Jan 7, 2026

@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.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jan 7, 2026

📝 Walkthrough

Walkthrough

This 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

Cohort / File(s) Summary
Routing Update
src/App.jsx
Updated import and route assignment: replaced VigyForm with VigyLogin component for vigy-login route; added clarifying comment identifying it as the Vigy (Seller) login page route.
New Login Component
src/User/pages/VigyLogin/VigyLogin.jsx
New VigyLogin component implementing seller login UI with form fields (email, password), password visibility toggle, remember-me checkbox, forgot-password link, and form submission handling via axios to VITE_API_URL endpoint; manages loading state with spinner, displays alerts via SweetAlert2, stores auth tokens and user metadata in localStorage, and navigates to dashboard on successful login.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

Suggested labels

good first issue, level3, gssoc

Suggested reviewers

  • codervivek5

Poem

🐰 A seller's login page now springs to life,
With passwords hidden from prying sight,
VigyLogin takes the stage so bright,
No more 404s causing strife—
The vigy-login route fixed just right! ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1
❌ 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%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely summarizes the main change: fixing the 404 error by adding a dedicated Vigy login page.
Description check ✅ Passed The description is comprehensive and includes the required sections (problem statement, solution, benefits) but does not follow the repository template structure with 'Fixes Issue', 'Changes proposed', 'Screenshots', and 'Note to reviewers' sections.
Linked Issues check ✅ Passed The PR fully addresses issue #2638 by implementing a dedicated VigyLogin component and updating routing so the 'Login as Vigy' button navigates to a proper login page instead of causing a 404 error.
Out of Scope Changes check ✅ Passed All changes are directly scoped to fixing the 404 error and implementing the Vigy login page. No unrelated modifications are present.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings

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.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between 796c229 and e3be213.

📒 Files selected for processing (2)
  • src/App.jsx
  • src/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-login to 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-form for registration purposes (line 215).

// Login state
const [loginEmail, setLoginEmail] = useState("");
const [loginPassword, setLoginPassword] = useState("");
const [rememberMe, setRememberMe] = useState(false);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

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.

Comment on lines +23 to +26
localStorage.setItem("accessToken", accessToken);
localStorage.setItem("username", username);
localStorage.setItem("isLoggedIn", "true");
localStorage.setItem("userType", "vigy"); // Mark as Vigy user
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Explore repository structure
echo "=== Repository structure ==="
git ls-files | head -30

Repository: 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 -50

Repository: 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 -20

Repository: 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 -20

Repository: 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 -40

Repository: 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 -80

Repository: codervivek5/VigyBag

Length of output: 3470


🏁 Script executed:

#!/bin/bash
# Check app.js for middleware configuration
echo "=== backend/app.js ==="
cat -n backend/app.js

Repository: 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 -15

Repository: 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 -30

Repository: 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 -20

Repository: 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 -100

Repository: 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 -20

Repository: 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 -50

Repository: 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.jsx

Repository: 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.js

Repository: 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 -40

Repository: 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 -10

Repository: 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 -10

Repository: 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.js

Repository: 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 -20

Repository: 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.js

Repository: 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" -n

Repository: 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.js

Repository: 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.js

Repository: 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 -20

Repository: 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.jsx

Repository: 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" -n

Repository: 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 -80

Repository: 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.jsx

Repository: 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 -30

Repository: 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.jsx

Repository: 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.

Comment on lines +27 to +29
if (role !== undefined) {
localStorage.setItem("role", role);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

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.

Comment on lines +51 to +54
const response = await axios.post(`${apiUrl}/auth/vigy-login`, {
email: loginEmail,
password: loginPassword,
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 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 -20

Repository: 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 -100

Repository: 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 -20

Repository: codervivek5/VigyBag

Length of output: 156


🏁 Script executed:

cat -n ./backend/routes/authRoutes.js

Repository: codervivek5/VigyBag

Length of output: 2553


🏁 Script executed:

cat -n ./backend/controllers/authController.js

Repository: 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:

  1. Update the frontend to call /auth/login instead of /auth/vigy-login, or
  2. Create a new /auth/vigy-login endpoint 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] "Login as Vigy" button redirects to 404 page

1 participant