Handle cookies when not allowed

[i2p-lbt]

I noticed a FedWiki does not display it's content properly even with Javascript enabled if cookies are forbidden. It took me a moment to realise what's the problem. I don't know if there is a technical reason, as the client should still be able to retrieve the content? So maybe that's even a bug. If not, maybe consider displaying a header with a warning if the cookie is not present but needed?

[WardCunningham]

I turned off cookies in firefox and got a blank screen with this console message (serving client.max.js from the recent wiki@beta)

The debugger directed me to this line. I can't explain the issue.

I'm not in favor of warning messages but I am in favor of understanding the logic behind this error. Perhaps @i2p-lbt can track down some documentation for us.

[WardCunningham]

Firefox reports these cookies for localhost.

[i2p-lbt]

I'm not in favor of warning messages but I am in favor of understanding the logic behind this error.

Understanding things is a good approach. Writing software that has dependencies in terms of requiring something but not determining if its available / not telling the user about it sounds like a bad concept. Hope you didn't mean it that way, as it doesn't allow the user to understand what's going on/wrong, either. If you dare to take a look outside, then check https://en.wikipedia.org/wiki/HTTP_cookie#EU_cookie_directive too - FedWikis might actually be kind of illegal in certain countries. Not sure if/how deep you want to get into that, but doesn't sound like you should generally ignore it, either.

And I don't know how the code is organised, so I'm probably not the right one to debug this at the moment. I don't have the max version, so what I see is:

Using //@ to indicate sourceMappingURL pragmas is deprecated. Use //# instead jquery-1.9.1.min.js:1:0
Using //@ to indicate sourceMappingURL pragmas is deprecated. Use //# instead jquery-migrate-1.1.1.min.js:3:0
"Window Name: ward.fed.wiki.org" client.js:3:458
SecurityError: The operation is insecure. client.js:3:0
Use of getPreventDefault() is deprecated.  Use defaultPrevented instead. jquery-1.9.1.min.js:3:0

This reference to line 3 then is not readable (minimised code, it's kind of a long line), but probably points to the same place as shown by you. Accessing the local storage for the first time here, maybe? It's been time since I played around with local storage, but as http://www.w3schools.com/HTML/html5_webstorage.asp points out:

Before using local storage, check browser support for localStorage and sessionStorage:

if(typeof(Storage) !== "undefined") {
    // Code for localStorage/sessionStorage.
} else {
    // Sorry! No Web Storage support..
}

In Firefox Local Storage is controlled by the cookie-policy, although they do not make that very clear in the UI. So while "no cookies", it's also "no local storage". We can capture that scenario rather well, though, with the above. There's actually more to it, though. If I understand the notes on Safari mobile at https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_AP correctly, then FedWiki will not work on those. On that page also read the section on Private Browsing Modes and the problems related to local storage. There several situations in which browsers will delete the local storage. But with an opt-in (making the user consciously chose her/his mode of operation), that's all resolved.

An according presence-check for cookies can be found at http://www.w3schools.com/js/js_cookies.asp. Now all of this is Javascript and thus depending on that being enabled. Checking Javascript on the server-side is not that trivial. The answer at http://stackoverflow.com/questions/121203/how-to-detect-if-javascript-is-disabled is worth reading (if that is an indicator for you, the question got 400+ upvotes and the answer 200+):

I assume that you're trying to decide whether or not to deliver JavaScript-enhanced content. The best implementations degrade cleanly, so that the site still operates without JavaScript. I guess that you mean server-side detection, rather than using the element.
There isn't a good way to perform server-side JavaScript detection. Instead, use JavaScript to set a cookie, and then test for that cookie using server-side scripting upon subsequent page views; deliver content appropriately.

Logically I fail to see a necessity for requiring a cookie to be set if only viewing a page without logging in, even if putting the privacy and legal issues aside. But technically this is pretty much the same thing to address as with the Javascript as can be seen from above. It should be easy to check for the presence of all of these as mentioned above and just deal with not having them. Only pointing this out to the user is the "easy" (in terms of fast to implement) way. But it should allow to address the legal issues I guess. Providing an alternative is what I would see as the proper way. Even if that alternative has limits, then. Let's point those out, too. At least that seems a sensible approach to me.