Your view on cookies?
-
Similar to the javascript poll, I wanted to get a feel for how people see/treat cookies. This one isn't going to be a poll since it's fairly subjective in nature.
I personally treat cookies as 'configuration state preservation' - Such as preserving expanded/collapsed menus, filtered views, etc. In some cases, cookies are a decent(ish) substitute for handling data in a different way if javascript is unavailable.
I'm still new to UI development though, so take my views with plenty of salt over the shoulder - feel free to chime in with 'why aren't you using [x] for that?'
What about you? Do you use cookies? Do you rely on javascript to be enabled and shunk cookies completely? Do you rely on cookies for more than just UI enhancements? Do you believe cookies should be eaten, and not left in the interwebz?
-
Cookies have two purposes.
One is for state preservation of things like preferences. Not my preference to do, and I tend to do that on the server side where possible, just because I prefer to keep user preferences accessible with user data (e.g. across platforms), which is the one use case cookies cannot meaningfully cover.
Yes, there are options like localStorage for such preferences (which means you don't send them back and forth with every request, but store locally), but they don't persist across platforms either, but if you can get that information to the user when they log in and occasionally sync that... if it suits your application to do that, it can be worth it. Ultimately I don't see cookies being useful for preferences - unless you want to preserve something stateful for users that don't have accounts. But again, local storage will be useful there.
One is for session management. HTTP is stateless as a protocol; theoretically a GET request is supposed to be idempotent. The concept of requests that include authorisation as a fundamental part of the request for stateful environments (i.e. being logged in to something) is simply not part of the specification. As a result, cookies absolutely must be used if you have any intention of doing sane user interaction.
Whatever you're doing then, you're going to be issuing some kind of token to the user to present as part of future requests for identification purposes. Cookies are the only medium that will return the token with requests back to the server, unless you manually make every request by hand having pulled the token from localStorage.
-
unless you want to preserve something stateful for users that don't have accounts
This is exactly what I'm using the cookies for in my current app (left nav bar, anonymous user - retain expanded/collapsed state)
I'm currently debating the design of my authorization module, but I'm leaning heavily towards the default asp.net authorization module. (DB auth + auth cookies + xsrf tokens, and probably going to sprinkle some other magic in there)
-
If you can rely users on having a more modern browser (IE8+, plus anything even reasonably sane in the other camps, like Chrome 4, FF 3.5, Opera 10.5), localStorage would probably be the way to go since it doesn't automagically get sent as part of every single request (even to things like images on the domain)
For preferences and such like it's pretty much the way to do it these days.
For auth, it sounds like you're going down the right direction too.
-
oh wow, local storage looks like it's highly supported, even on mobile platforms. (Minus opera mini, but whatever. Looking at you, @Onyx.)
I'll definitely look in to that instead of cookies, as I don't need the data going back and forth to the server. A single pull on each platform to sync the data for authed users, and just reuse what's there for non-authed users (or users who clear their local data)
-
@Arantor gave a canonical answer. Nothing more to say there.
-
I hope you're happy @Arantor. You killed an innocent thread. A newborn one. You monster.
-
You can introduce some controversy. Or something.
-
Local storage works well back to IE8. It is a good alternative to saving user preferences without them having to ever login.
-
Similar to the javascript poll, I wanted to get a feel for how people see/treat cookies. This one isn't going to be a poll since it's fairly subjective in nature.
I see them in the jar, and I treat me to them..
-
I use cookies quite regularly. Usually to soak in tea. XD
-
i like the chocolate, chocolate chip kind most. other cookies are just not as good.
-
The pretend-chocolate-chip ones are the worst. I hate raisins. I hate them even more when I'm expecting delicious chocolate.
-
Except for trivial things or session-length data, cookies should merely identify sessions and the session should store the UI state. That way, when the user moves to a second computer, their UI preferences follow them.
Session cookies are handy for a shitload of purposes, of course. I'm also ok with a long-term cookie to store a setting that isn't really all that important, like, for example, sort order of a list-- sure it's handy to save that, but if it's lost it's like one click to get it back.
Third-party cookies should never be relied on.
-
Local storage works well back to IE8. It is a good alternative to saving user preferences without them having to ever login.
I've always seen Local Storage as more a cache for potentially-expensive AJAX request data. For the app I'm building now, I retrieve a user's JSON object, then I need to grab the JSON object for every game mentioned in it-- this could potentially take a long time, so once it's retrieved I store it in the Local Storage as a cache.
But hey, you can use it for whatever.
-
Cookies are yet another thing for Europeans to over regulate.
-
Yes, and we managed to bollocks it up so well.
-
http://www.europeword.com/blog/wp-content/uploads/usa-vs-europe-3.jpg
Filed under: what hidden cookie agenda?
-
I'd be fine with them disappearing completely, provided that we have something better for authorization.
-
I'd be fine with them disappearing completely, provided that we have something better for authorization.
Client-certificate SSL?
(It is better except in one key way: it's a total pain to set up and administer, and the user is highly exposed to the most painful part.)
-
I'd be fine with them disappearing completely, provided that we have something better for authorization.
TLS-SRP, if browsers could ever implement it...(TL;DR: it's password authentication, but in a way that is both integrated at the session-level and highly secure)
