Fix: Login redirect to original destination

[timothyfroehlich]

Currently, when a non-logged-in user tries to access a protected route, the middleware correctly redirects them to /login?next=/original-path. However, the login process ignores this next parameter and always redirects the user to /dashboard upon successful authentication.

Problem Locations:

1. src/app/(auth)/login/page.tsx: If a user is already logged in and hits the login page with a next parameter, they are redirected to /dashboard instead of the next destination.
2. src/app/(auth)/login/login-form.tsx: Needs to capture the next search parameter from the URL and include it in the form (e.g., as a hidden input).
3. src/app/(auth)/actions.ts (loginAction): Needs to check for the next parameter in formData and redirect to it instead of /dashboard if present.

Proposed Solution:

1. Update LoginPage to read next from search params (if possible, though Server Components get params via props).
2. Update LoginForm to read next from useSearchParams or props.
3. Add <input type="hidden" name="next" value={next} /> to the form.
4. Update loginAction to:

   const next = formData.get("next") as string | null;
   redirect(next ?? "/dashboard");

[traycerai]

Plan

Observations

The middleware correctly redirects unauthenticated users to /login?next=/original-path, but the login flow ignores this parameter. The login page always redirects to /dashboard for already-logged-in users (line 21 in file:src/app/(auth)/login/page.tsx), the login form doesn't capture the next parameter, and the loginAction hardcodes the redirect to /dashboard (line 149 in file:src/app/(auth)/actions.ts). The codebase already has security utilities (isInternalUrl and resolveRedirectPath in file:src/app/auth/callback/route.ts) to prevent open redirect vulnerabilities.

Approach

Implement a three-layer fix: (1) update the login page to read and validate the next search parameter, (2) pass it to the login form as a prop and include it as a hidden input, and (3) modify the login action to read the next parameter from form data and redirect accordingly. Reuse existing security utilities to prevent open redirect attacks. This ensures users are redirected to their original destination after authentication while maintaining security best practices already established in the codebase.

Implementation Steps

1. Update Login Page (file:src/app/(auth)/login/page.tsx)

Modify the LoginPage component signature and logic:

• Add searchParams prop to the component signature (Next.js App Router pattern for Server Components)
• The prop type should be Promise<{ next?: string }> (Next.js 15+ async params pattern)
• Await the searchParams promise to extract the next parameter
• When checking if user is already logged in (lines 20-22), redirect to the next destination if present, otherwise /dashboard
• Pass the next parameter to the LoginForm component as a prop

Example structure:

export default async function LoginPage({
  searchParams,
}: {
  searchParams: Promise<{ next?: string }>;
})

2. Update Login Form (file:src/app/(auth)/login/login-form.tsx)

Add next parameter support:

• Add next?: string to the LoginFormProps interface (line 13-15)
• Accept the next prop in the component function signature (line 17-19)
• Add a hidden input field inside the form (after line 41) to include the next parameter:

  {next && <input type="hidden" name="next" value={next} />}

3. Update Login Action (file:src/app/(auth)/actions.ts)

Modify the loginAction function:

• Import the security utilities from the auth callback route:

  • isInternalUrl function
  • resolveRedirectPath function

  These can be extracted to a shared utility file (e.g., file:src/lib/auth/redirect-utils.ts) or imported directly from file:src/app/auth/callback/route.ts

• After successful authentication (line 148), before the redirect:

  • Extract the next parameter from formData: formData.get("next")
  • Validate it using isInternalUrl or resolveRedirectPath to prevent open redirect vulnerabilities
  • If valid and present, redirect to the next destination
  • Otherwise, redirect to /dashboard as the default

Example logic:

const nextParam = formData.get("next");
const next = typeof nextParam === "string" ? nextParam : null;

// Validate and resolve the redirect path
const redirectPath = next && isInternalUrl(next) ? next : "/dashboard";

redirect(redirectPath);

4. Security Considerations

Prevent open redirect vulnerabilities:

• Use the existing isInternalUrl function from file:src/app/auth/callback/route.ts (lines 17-20) to validate the next parameter
• Only allow internal paths (starting with / but not //)
• Reject any absolute URLs or protocol-relative URLs
• Default to /dashboard if validation fails

Alternative approach: Use the more comprehensive resolveRedirectPath function (lines 22-58) which handles additional edge cases like absolute URLs pointing to the same host.

5. Flow Diagram

sequenceDiagram
    participant User
    participant Middleware
    participant LoginPage
    participant LoginForm
    participant LoginAction
    participant Dashboard

    User->>Middleware: Access /protected-route (not logged in)
    Middleware->>LoginPage: Redirect to /login?next=/protected-route
    LoginPage->>LoginPage: Extract next from searchParams
    LoginPage->>LoginForm: Pass next as prop
    LoginForm->>LoginForm: Add hidden input with next value
    User->>LoginForm: Submit credentials
    LoginForm->>LoginAction: Submit form with next parameter
    LoginAction->>LoginAction: Validate credentials
    LoginAction->>LoginAction: Validate next parameter (isInternalUrl)
    alt next is valid
        LoginAction->>User: Redirect to /protected-route
    else next is invalid or missing
        LoginAction->>Dashboard: Redirect to /dashboard
    end

Loading

6. Edge Cases to Handle

• Empty or null next parameter: Default to /dashboard
• Invalid next parameter (external URL, protocol-relative): Reject and default to /dashboard
• Already logged-in user with next parameter: Redirect to next destination instead of /dashboard
• URL encoding: The middleware already encodes the path (line 125 in file:src/lib/supabase/middleware.ts), so no additional encoding needed in the login page

7. Files Modified

1. file:src/app/(auth)/login/page.tsx - Add searchParams prop, extract next, pass to form
2. file:src/app/(auth)/login/login-form.tsx - Accept next prop, add hidden input
3. file:src/app/(auth)/actions.ts - Read next from formData, validate, redirect accordingly

8. Optional: Extract Security Utilities

Consider extracting isInternalUrl and resolveRedirectPath from file:src/app/auth/callback/route.ts to a shared utility file like file:src/lib/auth/redirect-utils.ts for better code reuse and maintainability. This would allow both the callback route and login action to use the same validation logic.

Import In IDE

🤖 Prompt for AI Agents

## Observations

The middleware correctly redirects unauthenticated users to `/login?next=/original-path`, but the login flow ignores this parameter. The login page always redirects to `/dashboard` for already-logged-in users (line 21 in `file:src/app/(auth)/login/page.tsx`), the login form doesn't capture the `next` parameter, and the `loginAction` hardcodes the redirect to `/dashboard` (line 149 in `file:src/app/(auth)/actions.ts`). The codebase already has security utilities (`isInternalUrl` and `resolveRedirectPath` in `file:src/app/auth/callback/route.ts`) to prevent open redirect vulnerabilities.

## Approach

Implement a three-layer fix: (1) update the login page to read and validate the `next` search parameter, (2) pass it to the login form as a prop and include it as a hidden input, and (3) modify the login action to read the `next` parameter from form data and redirect accordingly. Reuse existing security utilities to prevent open redirect attacks. This ensures users are redirected to their original destination after authentication while maintaining security best practices already established in the codebase.

## Implementation Steps

### 1. Update Login Page (`file:src/app/(auth)/login/page.tsx`)

**Modify the `LoginPage` component signature and logic:**

- Add `searchParams` prop to the component signature (Next.js App Router pattern for Server Components)
- The prop type should be `Promise<{ next?: string }>` (Next.js 15+ async params pattern)
- Await the `searchParams` promise to extract the `next` parameter
- When checking if user is already logged in (lines 20-22), redirect to the `next` destination if present, otherwise `/dashboard`
- Pass the `next` parameter to the `LoginForm` component as a prop

**Example structure:**
```typescript
export default async function LoginPage({
  searchParams,
}: {
  searchParams: Promise<{ next?: string }>;
})
```

### 2. Update Login Form (`file:src/app/(auth)/login/login-form.tsx`)

**Add `next` parameter support:**

- Add `next?: string` to the `LoginFormProps` interface (line 13-15)
- Accept the `next` prop in the component function signature (line 17-19)
- Add a hidden input field inside the form (after line 41) to include the `next` parameter:
  ```typescript
  {next && <input type="hidden" name="next" value={next} />}
  ```

### 3. Update Login Action (`file:src/app/(auth)/actions.ts`)

**Modify the `loginAction` function:**

- Import the security utilities from the auth callback route:
  - `isInternalUrl` function
  - `resolveRedirectPath` function
  
  These can be extracted to a shared utility file (e.g., `file:src/lib/auth/redirect-utils.ts`) or imported directly from `file:src/app/auth/callback/route.ts`

- After successful authentication (line 148), before the redirect:
  - Extract the `next` parameter from `formData`: `formData.get("next")`
  - Validate it using `isInternalUrl` or `resolveRedirectPath` to prevent open redirect vulnerabilities
  - If valid and present, redirect to the `next` destination
  - Otherwise, redirect to `/dashboard` as the default

**Example logic:**
```typescript
const nextParam = formData.get("next");
const next = typeof nextParam === "string" ? nextParam : null;

// Validate and resolve the redirect path
const redirectPath = next && isInternalUrl(next) ? next : "/dashboard";

redirect(redirectPath);
```

### 4. Security Considerations

**Prevent open redirect vulnerabilities:**

- Use the existing `isInternalUrl` function from `file:src/app/auth/callback/route.ts` (lines 17-20) to validate the `next` parameter
- Only allow internal paths (starting with `/` but not `//`)
- Reject any absolute URLs or protocol-relative URLs
- Default to `/dashboard` if validation fails

**Alternative approach:** Use the more comprehensive `resolveRedirectPath` function (lines 22-58) which handles additional edge cases like absolute URLs pointing to the same host.

### 5. Flow Diagram

```mermaid
sequenceDiagram
    participant User
    participant Middleware
    participant LoginPage
    participant LoginForm
    participant LoginAction
    participant Dashboard

    User->>Middleware: Access /protected-route (not logged in)
    Middleware->>LoginPage: Redirect to /login?next=/protected-route
    LoginPage->>LoginPage: Extract next from searchParams
    LoginPage->>LoginForm: Pass next as prop
    LoginForm->>LoginForm: Add hidden input with next value
    User->>LoginForm: Submit credentials
    LoginForm->>LoginAction: Submit form with next parameter
    LoginAction->>LoginAction: Validate credentials
    LoginAction->>LoginAction: Validate next parameter (isInternalUrl)
    alt next is valid
        LoginAction->>User: Redirect to /protected-route
    else next is invalid or missing
        LoginAction->>Dashboard: Redirect to /dashboard
    end
```

### 6. Edge Cases to Handle

- **Empty or null `next` parameter**: Default to `/dashboard`
- **Invalid `next` parameter** (external URL, protocol-relative): Reject and default to `/dashboard`
- **Already logged-in user with `next` parameter**: Redirect to `next` destination instead of `/dashboard`
- **URL encoding**: The middleware already encodes the path (line 125 in `file:src/lib/supabase/middleware.ts`), so no additional encoding needed in the login page

### 7. Files Modified

1. `file:src/app/(auth)/login/page.tsx` - Add searchParams prop, extract next, pass to form
2. `file:src/app/(auth)/login/login-form.tsx` - Accept next prop, add hidden input
3. `file:src/app/(auth)/actions.ts` - Read next from formData, validate, redirect accordingly

### 8. Optional: Extract Security Utilities

Consider extracting `isInternalUrl` and `resolveRedirectPath` from `file:src/app/auth/callback/route.ts` to a shared utility file like `file:src/lib/auth/redirect-utils.ts` for better code reuse and maintainability. This would allow both the callback route and login action to use the same validation logic.

---

Execution Information

Branch: main
Commit: c18c2d3

---

💡 Tips

Supported Commands (Inside Comments)

• Use @traycerai generate to iterate on the previous version of the implementation plan.

Supported Commands (Inside Description)

• Add @traycerai ignore anywhere in the ticket description to prevent this ticket from being processed.
• Add @traycerai branch:<branch-name> anywhere in the ticket description to specify the target branch for the implementation plan.

Community

• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

Warning

Something went wrong while processing your request.

Reference ID: 2e456d65-40cc-4b98-a536-5b5e67bb1fb5

Please try again or contact support if the issue persists, referencing this ID.