Skip to content

[WIP] Fix hardcoded authentication in Protected route#14

Draft
Copilot wants to merge 1 commit intodevfrom
copilot/fix-authentication-hardcoded-true
Draft

[WIP] Fix hardcoded authentication in Protected route#14
Copilot wants to merge 1 commit intodevfrom
copilot/fix-authentication-hardcoded-true

Conversation

Copy link
Copy Markdown

Copilot AI commented Mar 14, 2026

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

Frontend Issues for Open Course

This document contains all identified issues in the frontend codebase, formatted for GitHub issue creation.


🔴 Critical Issues

1. Authentication Hardcoded to True - Security Vulnerability

File: src/routes/Protected.tsx

Severity: CRITICAL

Description:
The Protected route has hardcoded isAuthenticated = true, which bypasses all authentication checks. This is a security vulnerability that allows unauthenticated users to access protected routes.

let isAuthenticated = true; // This should use actual auth state from store

Expected Behavior:
Should check if user is authenticated via the auth store (useAuthStore).

Steps to Reproduce:

  1. Navigate to /dashboard without being logged in
  2. Observe that the page loads without authentication

Acceptance Criteria:

  • Use useAuthStore to get actual authentication state
  • Redirect unauthenticated users to /login
  • Add proper console errors for debugging in dev

2. Excessive Use of TypeScript any Type

Files: Multiple components throughout src/

Severity: HIGH

Description:
The codebase has excessive use of TypeScript any type, which defeats type safety. This leads to:

  • Poor IDE autocomplete
  • Runtime errors not caught at compile time
  • Difficult refactoring
  • Poor code maintainability

Examples:

  • CoursesPage.tsx line 12: function TrackCard({ to, icon, title, description, gradient, count, features, stats }:any
  • Interview.tsx line 120: function CategoryCard({ category, index }: any)
  • DashboardPage.tsx line 295: {uploads.slice(0, 3).map((video: any, index: number) => (
  • Login.tsx line 76: onChange={(e: any) => setEmail(e.target.value)}
  • Register.tsx line 103: onChange={(e: any) => update("firstName", e.target.value)}
  • Community.tsx line 669: }: any) {

Expected Behavior:
All component props should have proper TypeScript interface types.

Acceptance Criteria:

  • Create proper TypeScript interfaces for all component props
  • Replace all any types with proper types
  • Enable stricter TypeScript checking in tsconfig
  • No warnings from TypeScript compiler

3. Missing useCallback Dependencies

File: src/pages/contribute/modes/InterviewQuestions.tsx

Severity: HIGH

Description:
The addQuestion callback has incomplete dependencies array, which could cause stale closures and bugs:

const addQuestion = useCallback(() => {
  // ...
}, [currentQuestion, currentAnswer, currentDifficulty, questions])

Missing dependency: This should also depend on all state variables used inside the callback. The dependency list might cause the callback to be recreated unnecessarily or not recreated when needed.

Expected Behavior:
Dependencies should be accurately listed to prevent stale closure bugs.

Steps to Reproduce:

  1. Add a question
  2. Try to modify the field state
  3. Observe potential state inconsistencies

Acceptance Criteria:

  • Fix all useCallback dependency arrays
  • Run ESLint rule exhaustive-deps to catch all issues
  • Test that state updates work correctly

🟠 High Priority Issues

4. No Proper Error Handling in API Calls

Files: Multiple API integration files

Severity: HIGH

Description:
Several pages don't have proper error handling for failed API requests:

Examples:

Expected Behavior:
All API calls should have proper error handling with user-friendly messages via toast notifications.

Acceptance Criteria:

  • Replace generic catch blocks with proper error handling
  • Show error toast notifications for API failures
  • Log errors appropriately for debugging
  • Provide retry options for failed requests

5. useEnroll Hook Uses Only localStorage - Backend Sync Issue

File: src/hooks/useEnroll.ts

Severity: HIGH

Description:
The useEnroll hook only stores enrollment state in localStorage without syncing with the backend. This causes:

  • State inconsistency between frontend and backend
  • Lost enrollment data when localStorage is cleared
  • Multiple browser tabs showing different enrollment states
  • No real enrollment tracking on backend

Current Implementation:

export function useEnroll(courseId: string) {
  const [enrolled, setEnrolled] = useState(
    localStorage.getItem(`enrolled-${courseId}`) === "true"
  );

  function enroll() {
    localStorage.setItem(`enrolled-${courseId}`, "true");
    setEnrolled(true);
  }

  return { enrolled, enroll };
}

Expected Behavior:
Should make API calls to backend to manage enrollment state.

Acceptance Criteria:

  • Create API endpoint for enrollment management
  • Call backend enrollment API instead of localStorage
  • Handle API errors properly
  • Sync state across browser tabs using storage events
  • Show loading state during enrollment

6. console.error and console.log Left in Production Code

Files: Multiple files

Severity: MEDIUM-HIGH

Description:
Debug logging statements left in production code:

Examples:

  • Explore.tsx: console.error("Error fetching data:", err);

Expected Behavior:
No console statements should be left in production code. Use proper error tracking service (Sentry, LogRocket, etc.) if needed.

Acceptance Criteria:

  • Set up proper error tracking service
  • Remove all debug console logs
  • Use error tracking for production error monitoring
  • Implement structured logging

7. Redux Store Empty - Unclear State Management

File: src/redux/

Severity: MEDIUM-HIGH

Description:
The Redux store directory is empty, but Redux is imported in dependencies. The application uses Zustand for auth state management instead. This creates confusion about the intended state management pattern.

Expected Behavior:
Either:

  1. Remove Redux completely if not needed
  2. Properly implement Redux for application-wide state management

Acceptance Criteria:

  • Decide on state management pattern (Zustand or Redux)
  • Remove unused state management library from package.json
  • Update documentation
  • Migrate all state to chosen library if needed

🟡 Medium Priority Issues

8. Missing Loading States in List Components

Files: Multiple list/grid components

Severity: MEDIUM

Description:
Some components don't show loading indicators while fetching data:

Examples:

Expected Behavior:
All async operations should show loading states to users.

Acceptance Criteria:

  • Add loading state variables for all async operations
  • Show skeleton loaders or spinners while loading
  • Update UI when data is loaded or errored
  • Improve UX with proper feedback

9. Inadequate TypeScript Types for State Variables

Files: Dashboard, Courses, and Explore pages

Severity: MEDIUM

Description:
Many state variables use loose typing:

Examples:

  • CoursesPage.tsx: function TrackCard({ to, icon, title, description, gradient, count, features, stats }:any)
  • Dashboard.tsx: const [field, setField] = useState<any>(null);
  • CourseLearnPage.tsx: const [course, setCourse] = useState<any>(null);

Expected Behavior:
All state should have proper TypeScript interfaces.

Acceptance Criteria:

  • Define TypeScript interfaces for all data structures
  • Replace <any> with proper types
  • Export and reuse types from server types directory

10. No TypeScript Proper Types for React Event Handlers

Files: Multiple form components

Severity: MEDIUM

Description:
React event handlers use any type instead of proper React event types:

Examples:

onChange={(e: any) => setEmail(e.target.value)}  // Should be React.ChangeEvent<HTMLInputElement>
onKeyDown={(e: any) => e.key === "Enter"}        // Should be React.KeyboardEvent<HTMLInputElement>

Expected Behavior:
Use proper React event types from react package.

Acceptance Criteria:

  • Replace all any in event handlers with proper React types
  • Use React.ChangeEvent<HTMLInputElement>, React.KeyboardEvent, etc.
  • Update ESLint rules to catch these

11. Missing Null/Undefined Checks in Destructuring

File: CourseLearnPage.tsx

Severity: MEDIUM

Description:
Unsafe destructuring without null checks:

? (video.uploadedBy as any)?.username ?? "Community"

This uses unsafe type assertion with as any.

Expected Behavior:
Should have proper type guards and null checks.

Acceptance Criteria:

  • Remove unsafe as any assertions
  • Add proper type guards
  • Use optional chaining correctly

12. Session Management - No Token Refresh Implementation

File: src/api/client.ts

Severity: MEDIUM

Description:
Current token refresh logic only clears token on 401 error. This doesn't refresh expired tokens proactively. If a user's token expires during a request, they'll be logged out without warning.

Current Implementation:

if (err.response?.status === 401) {
  localStorage.removeItem("oc_token");
  localStorage.removeItem("oc_user");
}

Expected Behavior:
Should attempt to refresh token before clearing auth state, maintaining user session.

Acceptance Criteria:

  • Implement refresh token logic
  • Only redirect to login after refresh fails
  • Queue failed requests and retry after refresh
  • Handle multiple concurrent requests properly

🟢 Low Priority Issues

13. Missing Component Documentation

Severity: LOW

Description:
Components lack JSDoc comments explaining their purpose, props, and usage.

Expected Behavior:
All components should have documentation comments.

Acceptance Criteria:

  • Add JSDoc comments to all exported components
  • Document props with types and descriptions
  • Add usage examples for complex components

14. Inconsistent Error Messages

Files: Multiple pages

Severity: LOW

Description:
Error messages are inconsistent in format and detail level across the application.

Expected Behavior:
Error messages should follow a consistent format with actionable information.

Acceptance Criteria:

  • Create error message standards
  • Update all error messages to match standards
  • Add troubleshooting suggestions where appropriate

15. Missing Accessibility Attributes

Files: Multiple components

Severity: LOW

Description:
Some interactive elements lack accessibility attributes like aria-labels, role, etc.

Expected Behavior:
All interactive elements should be accessibility-compliant.

Acceptance Criteria:

  • Add ARIA labels to buttons
  • Add roles to custom components
  • Test with accessibility tools
  • Ensure keyboard navigation works

16. Unused Imports and Dead Code

File: src/pages/contribute/Contribute.old.tsx

Severity: LOW

Description:
The file Contribute.old.tsx appears to be old/unused code that should be removed.

Expected Behavior:
Remove redundant/deprecated files.

Acceptance Criteria:

  • Verify Contribute.old.tsx is not used
  • Remove the file
  • Remove any associated imports

17. Missing Input Validation on Forms

Files: Register.tsx, Login.tsx, InterviewQuestions.tsx

Severity: MEDIUM

Description:
Forms have minimal client-side validation. While server-side validation is important, client-side validation improves UX.

Expected Behavior:
Forms should have comprehensive client-side validation.

Acceptance Criteria:

  • Add email format validation
  • Add password strength validation
  • Add required field validation
  • Show validation errors in real-time
  • Disable submit button when invalid

18. OAuth Integration Not Implemented

File: Login.tsx

Severity: MEDIUM

Description:
OAuth login buttons are present but not functional. They show in UI but don't have click handlers or API integration.

Current Implementation:

<OAuthButton icon={<Mail />} label="Google" />
<OAuthButton icon={<Github />} label="GitHub" />

Expected Behavior:
OAuth buttons should trigger OAuth flow or be removed if not planned.

Acceptance Criteria:

  • Implement OAuth integration with Google and GitHub
  • OR remove OAuth buttons from UI if not planned
  • Show clear feedback during OAuth flow
  • Handle OAuth errors gracefully

19. Missing Toast Notification for Success Cases

Files: Multiple pages

Severity: LOW

Description:
Some successful operations don't show confirmation toasts to users.

Expected Behavior:
All successful operations should show toast notifications.

Acceptance Criteria:

  • Add success toasts to all CRUD operations
  • Remove unnecessary success toasts (avoid toast fatigue)
  • Use consistent toast styling
  • Configure appropriate auto-close times

20. TypeScript Configuration Too Loose

File: tsconfig.json

Severity: MEDIUM

Description:
TypeScript compiler settings might be too loose, allowing too many implicit any types and unsafe code.

Expected Behavior:
TypeScript should be stricter to catch more errors at compile time.

Acceptance Criteria:

  • Enable strict mode
  • Set noImplicitAny: true
  • Set strictNullChecks: true
  • Set strictFunctionTypes: true
  • Address all newly reported errors

21. Missing API Error Types

Files: API integration files

Severity: MEDIUM

Description:
API error handling uses generic any type and doesn't properly type error responses.

Expected Behavior:
API error responses should have typed interfaces.

Acceptance Criteria:

  • Create typed error interfaces
  • Properly type API responses
  • Use discriminated unions for error handling
  • Create error utility functions

22. localStorage Not Synced Across Tabs

File: src/store/auth.store.ts

Severity: MEDIUM

Description:
When auth state is updated in one tab, other tabs don't reflect the changes. This causes inconsistent state across multiple windows.

Expected Behavior:
Auth state should be synced across browser tabs using storage events.

Acceptance Criteria:

  • Listen to storage events
  • Update auth state when other tabs change it
  • Handle logout from other tabs
  • Display user-friendly message about logout

23. No Loading State for Authentication Operations

Files: Login.tsx, Register.tsx

Severity: LOW

Description:
While loading state exists, it could have better UX. Buttons don't disable during submission in all cases.

Expected Behavior:
Should disable form inputs and show better loading feedback.

Acceptance Criteria:

  • Disable form during submission
  • Show loading spinner on button
  • Disable submit button while loading
  • Clear form after successful registration

24. Missing URL Validation for Video Uploads

Files: Video upload components

Severity: LOW

Description:
Video URL inputs might not be properly validated for format.

Expected Behavior:
Should validate that input is a valid video URL.

Acceptance Criteria:

  • Add URL format validation
  • Test with various URL formats
  • Show clear error messages
  • Support multiple video platform URLs

25. Duplicated API Client Setup

Files: src/api/courses.api.ts and other API files

Severity: LOW

Description:
Multiple API client files might be duplicating similar functionality that could be refactored.

Expected Behavior:
API layer should be DRY without code duplication.

Acceptance Criteria:

  • Review all API files for duplication
  • Create shared utilities for common patterns
  • Consolidate similar functionality
  • Document API structure


Summary Statistics

Severity Count
CRITICAL 1
HIGH 6
MEDIUM-HIGH 3
MEDIUM 10
LOW 5
TOTAL 25

Quick Wins (Easy to Fix)

  1. Issue Migrate : Update old API endpoints for new version #9 - Remove Contribute.old.tsx
  2. Issue Explore course link not working on home page #6 - Remove console.error statements
  3. Issue remove performace section #18 - Remove OAuth buttons (if not planned) or create issue for implementation
  4. Issue [WIP] Fix hardcoded authentication in protected route #13 - Add JSDoc comments
  5. Issue explore Link broken in Header #1 - Fix protected routes (CRITICAL, should be done first)

Dependencies Between Issues


just create issue do not solve please just raise issue for all of them


💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.

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.

2 participants