221–230 of 270 posts
Earlier quoted context omitted.
This is a completely different topic though, and I think there's interest in shipping something like that. That's the main problem with “just add namespace FFS” discussions that come every other week: everyone has its own vision of what namespace should look like and what they are meant for, but nobody has ever taken the time to write an RFC with supporting arguments. In fact, people bring this mostly in ways that ar…
> nobody has ever taken the time to write an RFC with supporting arguments. https://rust-lang.github.io/rfcs/3243-packages-as-optional-n... https://github.com/rust-lang/rfcs/pull/3243
This isn't the kind of namespace people say they want to prevent squatting.
The article mocks Postel's law, but if the setter of the cookie had been conservative in what they sent, there would have been no need for the article...
> The article mocks Postel's law As they should. Postel's Law was a terrible idea and has created minefields all over the place. Sometimes, those mines aren't just bugs, but create gaping security holes. If your client is sending data that doesn't conform to spec, you have a bug, and you need to fix it. It should never be up to the server to figure out what you meant and accept it.
Earlier quoted context omitted.
They are not bad they just are unnecessary. If your application uses local state, use local storage. If you store session data on the server, identify the user using the Authorization header. Why send arbitrary strings back and forth often with requests that don’t need them. Plus the technology is clearly rotten. They never got namespacing snd expiration right so you can just do weird stuff with them. Also, CSRF woul…
> if you store session data on the server, identify the user using the Authorization header. And by what miracle browser would send Authorization header? Who sets it? For which domain it could be set?
Earlier quoted context omitted.
I think they mean storing an identifier in local or session storage and then sending it in the header.
Identifier in local storage could be stolen by 3rd party JavaScript. Anybody who wants to use local storage for sensitive information should read why there is a httpOnly cookie attribute.
And I am not suggesting using local storage for it. I am suggesting adding browser support for standard/generic login UI. Basically think basic auth, just not so basic.
Cookies are filled with weird gotchas and uncomfortable behavior that works 99.95% of the time. My favorite cookie minefield is cookie shadowing - if you set cookies with the same name but different key properties (domain, path, etc.) you can get multiple near-identical cookies set at once - with no ability for the backend or JS to tell which is which. Try going to https://example.com/somepath and entering the follow…
... this came up recently after I tightened the validation in jshttp/cookie https://github.com/jshttp/cookie/pull/167 - since that PR the validation has been loosened again a bit, similar to the browser code mentioned in the article.
My changes were prompted by finding a bug in our code (not jshttp) where a cookie header was constructed by mashing the strings together without encoding; every so often a value would have a space and break requests. I was going to suggest using jshttp/cookie's serialize() to devs to avoid this but then realized that that didn't validate well enough to catch the bug we'd seen. I proposed a fix, and someone else then spotted that the validation was loose enough you could slip js into the _name_ field of the cookie which would be interpreted elsewhere as the _value_, providing an unusal vector for code injection.
Earlier quoted context omitted.
It means that you are setting cookies on whatever page you're on, without considering whether the cookie will be consistently accessible on other pages. For example, you set the currency to EUR in /product/123, but when you navigate to /cart and refresh, it's back to USD. You change it again to EUR, only to realize in /cart/checkout that the USD pricing is actually better. So you try to set it back to USD, but now th…
If you want cookies to be global, set them to / or leave out the path. If you want more fine-grained cookies, use a specific path. What's the problem? Currency is—in your example—clearly a site-wide setting. I think sites should make more of their hierarchical structure, not less.
If not for this default behavior, it would have been much easier to manage global settings such as currency. Right now, all it takes is one cookie without a path to introduce inconsistency, only on some pages, in a way that's hard to reproduce.
Earlier quoted context omitted.
Why not do it like go does and use the git hosting domain as a prefix (like github.com/org/project)?
How does it prevent squatting in any way?
Earlier quoted context omitted.
It means that you are setting cookies on whatever page you're on, without considering whether the cookie will be consistently accessible on other pages. For example, you set the currency to EUR in /product/123, but when you navigate to /cart and refresh, it's back to USD. You change it again to EUR, only to realize in /cart/checkout that the USD pricing is actually better. So you try to set it back to USD, but now th…
Isn't that just the feature working as intended? Of course it is possible to introduce a bug by setting or not setting a cookie somewhere where it should/shouldn't be set. I've never found a use for path-based cookies personally, but I'm not sure this is a particularly compelling example.
Earlier quoted context omitted.
The problem is that it's a prisoner's dilemma. And you can't cooperate on a prisoner's dilemma against the entire world.
So, just be as conservative as possible when you produce data and as liberal as possible when you receive something. Your code will then require the least cooperation from *any* other code to be compatible with. Doing otherwise will require cooperation to adjust on the specificities clients expect, and you fall into the trap of the prisoner dilemna.
Being liberal on what you accept is a path for disaster.