Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cookies not available in GET method of Route Handlers #47682

Closed
1 task done
dijonmusters opened this issue Mar 30, 2023 · 3 comments
Closed
1 task done

Cookies not available in GET method of Route Handlers #47682

dijonmusters opened this issue Mar 30, 2023 · 3 comments
Labels
area: app App directory (appDir: true) bug Issue was opened via the bug report template.

Comments

@dijonmusters
Copy link
Contributor

Verify canary release

  • I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.3.0: Mon Jan 30 20:38:37 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.17.0
      npm: 8.15.0
      Yarn: N/A
      pnpm: 7.9.3
    Relevant packages:
      next: 13.2.5-canary.21
      eslint-config-next: 13.2.4
      react: 18.2.0
      react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true)

Link to the code that reproduces this issue

https://github.com/dijonmusters/route-handlers-cookies-bug

To Reproduce

  1. Run npm run dev
  2. Navigate to 'http://localhost:3000'
  3. Refresh the page
  4. Check dev console to confirm that cookiesList is an empty array []

Describe the Bug

Cookies are not being correctly sent to the GET method of Route Handlers.

If you do this for a POST or PUT request it sends the correct cookies - only seems to be a problem with the GET method in Route Handlers.

Expected Behavior

cookiesList should contain a cookie test=yep

Which browser are you using? (if relevant)

Arc Version 0.95.1 (37921)

How are you deploying your application? (if relevant)

No response

@dijonmusters dijonmusters added the bug Issue was opened via the bug report template. label Mar 30, 2023
@github-actions github-actions bot added the area: app App directory (appDir: true) label Mar 30, 2023
@wyattjoh
Copy link
Member

The issue with your reproduction is that the fetch is occuring in the server component (the <Home /> component in app/page.tsx).

While the fetch does hit the correct endpoint, it will not bubble up the cookies set on the response from the app/page.tsx.

If you instead modified this to import a component that's a client component, like:

"use client";

import { useEffect } from "react";

export default function Handler() {
  useEffect(() => {
    const run = async () => {
      const response = await fetch("/api/hello");
      const json = await response.json();
      console.log({ json });
    };

    run();
  }, []);

  return null;
}

And then import that component into the app/page.tsx file, you'll notice that it does set the correct cookies, and forward them! This is also because the default parameter for the fetch option of credentials is same-origin which will automatically forward the cookies alongside the request.

@jacobkapitein
Copy link

jacobkapitein commented Apr 6, 2023

Seems like this issue is fixed in the canary release.

npm install next@canary react@latest react-dom@latest

#47718

So this should be fixed in 13.2.5 🚀

@github-actions
Copy link
Contributor

github-actions bot commented May 7, 2023

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: app App directory (appDir: true) bug Issue was opened via the bug report template.
Projects
None yet
Development

No branches or pull requests

3 participants