Can you elaborate? I'm having a tough time finding references to that. (Disclaimer: I'm not an avid JS developer)

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 the cookie at /cart conflicts with the one at /cart/checkout because each page has its own cookie.

▲

oneeyedpigeon a year ago | parent | next [-]

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.

	▲	kijin a year ago \| parent [-]
		If you leave out the path, it will default to the directory of the current URL, not /. 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.

▲

foldr a year ago | parent | prev [-]

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.

▲

speleding a year ago | parent [-]

The typical example of a path-based cookie is the "remember my login name" feature, where you want the cookie with the user name only available on the login page. (And you cannot use session storage because you want it to work whilst logged out.)

▲

Xelynega a year ago | parent [-]

You don't need to store multiple login names for seperate pages though, so why can't this just be a site wide cookie?

	▲	speleding a year ago \| parent [-]
		That would include the cookie with each request, which is inefficient. And potentially it also can get sent with requests to other subdomains, which may not be desirable from a security point of view (it could be cdn.example.com, owned by someone else)

▲

teaearlgraycold a year ago | parent | prev [-]

For modern applications you’ll have better ways to maintain state. As shown they cause trouble in practice. Cookies should be used sparingly.

▲

prokopton a year ago | parent [-]

If you want to maintain state across navigations and share that state with a server it’s the best we’ve got.

▲

bpicolo a year ago | parent [-]

Server can store session state

▲

telgareith a year ago | parent [-]

Server side session state for more than authentication is way worse than "code smell."

It requires a ping to a shared data source on every request. And, the same one for all of them. No sharding, No split domains... That gets expensive fast!

▲

naasking a year ago | parent | next [-]

You just described how the whole web operates. It works just fine.

▲

MBCook a year ago | parent [-]

Even if you want client side, we have better ways now than cookies.

	▲	inopinatus a year ago \| parent [-]
		We do, but only cookies are universally available. Plenty of unusual user-agents in the world, or people like me that browse with JS off by default.

▲

CrimsonRain a year ago | parent | prev | next [-]

I add some products in phone. Then I login to desktop later for modification and order. Cart is empty. That's engineering smell. A really bad one.

	▲	telgareith a year ago \| parent [-]
		Thats nothing more than UX/UI. > In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem. Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology. - https://en.wikipedia.org/wiki/Code_smell

▲

paledot a year ago | parent | prev [-]

Wait, you can't shard on session ID?

And this is an ephemeral key-value store here, which is basically a best-case scenario from a performance standpoint. It's basically the last thing you're going to need to think about sharding, which is why session stores traditionally cohabitate(d) with web servers.

No, session storage doesn't get expensive fast. It's extraordinarily cheap unless you screw up the configuration very badly indeed (Apparently PHP still defaults to writing session data to disk?!)