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

AstroCookies.delete does not support __Host- and __Secure- prefixed cookies #10480

Closed
1 task done
fshafiee opened this issue Mar 18, 2024 · 5 comments · Fixed by #10671
Closed
1 task done

AstroCookies.delete does not support __Host- and __Secure- prefixed cookies #10480

fshafiee opened this issue Mar 18, 2024 · 5 comments · Fixed by #10671
Assignees
Labels
- P3: minor bug An edge case that only affects very specific usage (priority)

Comments

@fshafiee
Copy link
Contributor

Astro Info

Astro version is irrelevant as you’ll see in the bug description, but here it is:

Astro                    v3.6.5
Node                     v20.10.0
System                   macOS (arm64)
Package Manager          pnpm
Output                   server
Adapter                  @astrojs/node
Integrations             @astrojs/react
                         @astrojs/tailwind

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

The AstroCookies.delete API does not work for cookies with __Host- and __Secure- prefixes.

From MDN web docs:

__Host-
If a cookie name has this prefix, it's accepted in a Set-Cookie header only if it's also marked with the Secure attribute, was sent from a secure origin, does not include a Domain attribute, and has the Path attribute set to /. This way, these cookies can be seen as "domain-locked".
__Secure-
If a cookie name has this prefix, it's accepted in a Set-Cookie header only if it's marked with the Secure attribute and was sent from a secure origin. This is weaker than the __Host- prefix.

The key takeaway is the Secure attribute requirement, which based on the main branch of the repo, is not recognized by the AstroCookies.delete method:

type AstroCookieDeleteOptions = Pick<AstroCookieSetOptions, 'domain' | 'path'>;

As an example, this is how the Chrome treats Set-Cookie headers that violate these requirements:

Screenshot 2024-03-18 at 6 38 00 PM

What's the expected result?

The AstroCookies.delete method should recognize all standard cookie attributes, except for the maxAge and expires, since these are the only attributes that set a valid cookie apart from its expired version.

My current workaround is to use the AstroCookies.set method as follows:

Astro.cookies.set("cookie-name", "deleted", {
    expires: new Date(0),
    secure: true,
    path: "/",
    httpOnly: true, 
})

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-avarao?file=README.md

Participation

  • I am willing to submit a pull request for this issue.
@github-actions github-actions bot added the needs triage Issue needs to be triaged label Mar 18, 2024
@lilnasy lilnasy added the - P3: minor bug An edge case that only affects very specific usage (priority) label Mar 19, 2024
@github-actions github-actions bot removed the needs triage Issue needs to be triaged label Mar 19, 2024
@lilnasy
Copy link
Contributor

lilnasy commented Mar 19, 2024

Thanks for opening this issue. This seems like an important limitation of the Cookies API, the delete method has only two options.

I think it makes sense to allow httpOnly and secure as well. Do you know if those two will be enough for __Host-?

@fshafiee
Copy link
Contributor Author

fshafiee commented Mar 26, 2024

Hey @lilnasy,

Adding those flags would work in this case. However, this seems to be highly browser-dependent. For example, Chrome will also take partition attribute into account when trying to match existing cookies (which isn’t recognized by Astro, yet). And I have seen mixed behavior in the past when it comes to httpOnly.

My suggestion is to exclude value, maxAge, and expires cookie attributes when it comes to delete cookie API. It’s been a good practice for me to make sure the cookie attributes always match to ensure compatibility across browsers and different implementations.

However, if you insist on keeping the API surface limited, then yes, httpOnly and secure attributes are the absolute minimums that needs to be added to the delete API.

@lilnasy
Copy link
Contributor

lilnasy commented Mar 29, 2024

@fshafiee Thanks, shifting from Pick to Exclude is what I was thinking too. Are you interested in implementing it?

@fshafiee
Copy link
Contributor Author

fshafiee commented Apr 1, 2024

Of course @lilnasy. I'll open a PR in next few days.

@ematipico
Copy link
Member

I assigned the issue to you @fshafiee

Let us know if you need any help or you have questions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
- P3: minor bug An edge case that only affects very specific usage (priority)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants