-
-
Notifications
You must be signed in to change notification settings - Fork 117
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
Removing cookies by name #199
Comments
I second this, being the one that pushed @imbolc into making this by asking/requesting this at imbolc/tower-cookies#14 |
I'm not sure what's being proposed, exactly. Given the API you're suggesting, it seems like the crux of the proposal is to allow cookies to be removed via either 1) an It seems that given imbolc/tower-cookies#14 (comment), the reason the API is as it is today is understood: to avoid the common case where a user thinks a cookie will be removed but, because of a mismatched Given that, perhaps we could consider an API that looks like: fn remove_named<P, D>(&mut self, name: &str, path: P, domain: D)
where P: Into<Option<&str>>, D: Into<Option<&str>>; Such an API use would look like: let mut jar = some_jar;
jar.remove_named("cookie_name", None, None);
jar.remove_named("cookie_name", "/", None);
jar.remove_named("cookie_name", None, "crates.io");
jar.remove_named("cookie_name", "/", "crates.io"); This is in contrast to the API now: let mut jar = some_jar;
jar.remove(Cookie::named("cookie_name"));
jar.remove(Cookie::build("cookie_name", "").path("/").finish());
jar.remove(Cookie::build("cookie_name", "").domain("crates.io").finish());
jar.remove(Cookie::build("cookie_name", "").path("/").domain("crates.io").finish()); The first API suffers from unnamed parameters in an API that may be security sensitive while being pithy. The latter suffers from verbosity but is fairly clear otherwise. The latter also has the advantage that you can take a Both seem unideal in some ways, so let me propose yet another idea: // Change `remove()` to:
fn remove<C: Into<Cookie<'_>>(&mut self, cookie: C);
// Change `Cookie::named()` to:
pub fn named<N>(name: N) -> CookieBuilder<'c>
where N: Into<Cow<'c, str>>;
// Add the following:
impl Into<Cookie<'_>> for CookieBuilder<'_>; Now, the API use would look like: let mut jar = some_jar;
jar.remove(Cookie::named("cookie_name"));
jar.remove(Cookie::named("cookie_name").path("/"));
jar.remove(Cookie::named("cookie_name").domain("crates.io"));
jar.remove(Cookie::named("cookie_name").path("/").domain("crates.io")); This is almost as pithy as the |
Exactly
Right. I've learned about path and domain years ago, but frameworks I used afterwards let me happily forget about them e.g.:
Even pub fn new<N, V>(name: N, value: V) -> Self
{
Cookie {
...
domain: None,
path: None,
Would you maybe elaborate on this? In particular I don't see how passing
Agreed, I certainly wouldn't use
It's nice to remove a need for |
Finally address and released in v0.18.0-rc.0 - CHANGELOG incoming, but docs and message in 49ff7b0 should suffice for now. If you could give a try, I'd be grateful. |
Maybe you're willing to accept something like this here?
The api would become
The implementation is here: https://github.com/imbolc/tower-cookies/blob/2bbd9226188c6a18c80086b397aa34fcc42d8f68/src/lib.rs#L198
The text was updated successfully, but these errors were encountered: