FAQ Topic - How can I see in javascript if a web browser accepts cookies? (2009-12-20)
FAQ server
FAQ Topic - How can I see in javascript if a web browser
accepts cookies?
-----------------------------------------------------------------------
Write a cookie and read it back and check if it's the same.
Additional Notes:
http://www.ietf.org/rfc/rfc2965.txt
http://www.galasoft-lb.ch/myjavascript/consulting/2001012701/
The complete comp.lang.javascript FAQ is at
http://jibbering.com/faq/
--
The sendings of these daily posts are proficiently hosted
by http://www.pair.com.
Garrett Smith
> -----------------------------------------------------------------------
> FAQ Topic - How can I see in javascript if a web browser
> accepts cookies?
> -----------------------------------------------------------------------
>
> Write a cookie and read it back and check if it's the same.
>
> Additional Notes:
>
> http://www.ietf.org/rfc/rfc2965.txt
>
> http://www.galasoft-lb.ch/myjavascript/consulting/2001012701/
> http://www.cookiecentral.com/
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
Thomas 'PointedEars' Lahn
> FAQ server wrote:
>> -----------------------------------------------------------------------
>> FAQ Topic - How can I see in javascript if a web browser
>> accepts cookies?
>> -----------------------------------------------------------------------
>>
>> Write a cookie and read it back and check if it's the same.
>>
>> Additional Notes:
>>
>> http://www.ietf.org/rfc/rfc2965.txt
>>
>> http://www.galasoft-lb.ch/myjavascript/consulting/2001012701/
>> http://www.cookiecentral.com/
> Are there no better references for cookies?
<https://developer.mozilla.org/en/DOM/document.cookie>
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Garrett Smith
> Garrett Smith wrote:
>
>> FAQ server wrote:
>>> -----------------------------------------------------------------------
>>> FAQ Topic - How can I see in javascript if a web browser
>>> accepts cookies?
>>> -----------------------------------------------------------------------
>>>
>>> Write a cookie and read it back and check if it's the same.
>>>
>>> Additional Notes:
>>>
>>> http://www.ietf.org/rfc/rfc2965.txt
>>>
>>> http://www.galasoft-lb.ch/myjavascript/consulting/2001012701/
>>> http://www.cookiecentral.com/
>> Are there no better references for cookies?
>
> <https://developer.mozilla.org/en/DOM/document.cookie>
>
OK - Good one.
That can replace the links to galasoft and cookiecentral.
The FAQ should provide (link to) a set of good CrUD cookie functions.
The cookie API is painful to use. A program that uses cookies should
prefer a hand-rolled API to get the job done.
Dr J R Stockton
september.org>, Mon, 21 Dec 2009 15:31:12, Garrett Smith
<dhtmlk...@gmail.com> posted:
>Thomas 'PointedEars' Lahn wrote:
>> Garrett Smith wrote:
>>
>>> FAQ server wrote:
>>>> -----------------------------------------------------------------------
>>>> FAQ Topic - How can I see in javascript if a web browser
>>>> accepts cookies?
>>>> -----------------------------------------------------------------------
>>>>
>>>> Write a cookie and read it back and check if it's the same.
>>>>
>>>> Additional Notes:
>>>>
>>>> http://www.ietf.org/rfc/rfc2965.txt
>>>>
>>>> http://www.galasoft-lb.ch/myjavascript/consulting/2001012701/
>>>> http://www.cookiecentral.com/
>>> Are there no better references for cookies?
>> <https://developer.mozilla.org/en/DOM/document.cookie>
>>
>
>OK - Good one.
>
>That can replace the links to galasoft and cookiecentral.
No. It is good to include authoritative definitions such as RFCs, MAN
pages, https://developer.mozilla.org/en/. But, to normal people - we
see some here from time to time, pages such as those two are much better
at giving the general idea. Add document.cookie, but keep the others.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7)
Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)
Thomas 'PointedEars' Lahn
> Garrett Smith posted:
>> Thomas 'PointedEars' Lahn wrote:
>>> Garrett Smith wrote:
>>>> FAQ server wrote:
>>>>>
-----------------------------------------------------------------------
>>>>> FAQ Topic - How can I see in javascript if a web browser
>>>>> accepts cookies?
>>>>>
-----------------------------------------------------------------------
>>>>>
>>>>> Write a cookie and read it back and check if it's the same.
>>>>>
>>>>> Additional Notes:
>>>>>
>>>>> http://www.ietf.org/rfc/rfc2965.txt
>>>>>
>>>>> http://www.galasoft-lb.ch/myjavascript/consulting/2001012701/
>>>>> http://www.cookiecentral.com/
>>>> Are there no better references for cookies?
>>> <https://developer.mozilla.org/en/DOM/document.cookie>
>> OK - Good one.
>>
>> That can replace the links to galasoft and cookiecentral.
It should need to, for the "information" that can be found at galasoft and
cookiecentral is hopelessly outdated and potentially harmful, as can be seen
below.
> No. It is good to include authoritative definitions such as RFCs, MAN
> pages, https://developer.mozilla.org/en/. But, to normal people - we
> see some here from time to time, pages such as those two are much better
> at giving the general idea. Add document.cookie, but keep the others.
Those "normal people" you are talking about are not able to see those
references for the junk that they are. As a result, they will be producing
bad code although that could be avoided. And apparently either you have not
double-checked what you are defending, or you are completely lost. I can
only hope the former applies.
At <http://www.galasoft-lb.ch/myjavascript/consulting/2001012701/>:
- lack of code style
- invalid markup
- potentially harmful markup
- misuse of setTime() with regard to days
- misuse of the BR element
- deprecated use of alert()
- syntactically invalid code (a "normal person" would assume `<SCRIPT ...>'
belongs in cookie.js)
- deprecated use of escape()/unescape() and toGMTString()
- needlessly inefficient code
- misuse of setTime() with regard to deleting cookies
At <http://www.cookiecentral.com/>, in
<http://www.cookiecentral.com/c_concept.htm> (which is the only part of the
site referring to cookies anyway).
- misconceptions
"In most cases, not only does the storage of personal information into a
cookie go unnoticed"; "Cookies are based on a two-stage process. First
the cookie is stored in the user's computer without their consent or
knowledge."; "The user's Web browser, if cookie-savvy, receives the
cookie and stores it in a special file called a cookie list. This happens
without any notification or user consent."
- hopelessly outdated information
"In Internet Explorer
Actually, if you want to keep cookies but want rid of the double-click
place and other future invasions in the future, try this: Internet
Explorer 3.0 no longer has a single cookies.txt it has a folder in the
windows directory with lots of individual txt file inside. Find the
double-click one and corrupt it so that double-click recognizes and
doesn't replace it but it gives it no information. Then lock the file.
Hm, hm. Internet Explorer 3.0. Very relevant today :-> And manual
editing of cookie files, perhaps while the browser is running? No, no,
that's not potentially harmful, we never needed the current UI in the
first place! :->
"In Netscape
I have found a way to protect myself from the "Cookie Monster". My
cookies.txt and netscape.hst files are set to 0 (zero) bytes and are
attributed as system, hidden, and read only. This seems to work very well
in Netscape Navigator 2.02 (32 bit)."
Hm, hm. A hopelessly obsolete version full of security leaks of a Web
browser which producer does no longer exist since 6 years, and which
current vendor not only has ended support for the last version on
March 1st, 2008, but also recommends using alternative products of other
vendors instead. Yes, very relevant to Web programming nowadays.
A must have! :->
If you still want to have this nonsense referred on the Web, pray do it at
your site. It clearly does not belong in the comp.lang.javascript FAQ, or
any reasonable developer's site for that matter.
Garrett Smith
> Dr J R Stockton wrote:
>
>> Garrett Smith posted:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Garrett Smith wrote:
>>>>> FAQ server wrote:
> -----------------------------------------------------------------------
>>>>>> FAQ Topic - How can I see in javascript if a web browser
>>>>>> accepts cookies?
>>>>>>
> -----------------------------------------------------------------------
>>>>>> Write a cookie and read it back and check if it's the same.
>>>>>>
>>>>>> Additional Notes:
>>>>>>
>>>>>> http://www.ietf.org/rfc/rfc2965.txt
>>>>>>
>>>>>> http://www.galasoft-lb.ch/myjavascript/consulting/2001012701/
>>>>>> http://www.cookiecentral.com/
>>>>> Are there no better references for cookies?
>>>> <https://developer.mozilla.org/en/DOM/document.cookie>
>>> OK - Good one.
>>>
>>> That can replace the links to galasoft and cookiecentral.
>
> It should need to, for the "information" that can be found at galasoft and
> cookiecentral is hopelessly outdated and potentially harmful, as can be seen
> below.
>
I added the MDC link and removed the other two.
>> No. It is good to include authoritative definitions such as RFCs, MAN
>> pages, https://developer.mozilla.org/en/. But, to normal people - we
>> see some here from time to time, pages such as those two are much better
>> at giving the general idea. Add document.cookie, but keep the others.
>
> Those "normal people" you are talking about are not able to see those
> references for the junk that they are. As a result, they will be producing
> bad code although that could be avoided. And apparently either you have not
> double-checked what you are defending, or you are completely lost. I can
> only hope the former applies.
>
> At <http://www.galasoft-lb.ch/myjavascript/consulting/2001012701/>:
>
OK, so that document is no good, but Stockton has a point: There should
be a tutorial/example reference for cookies. That document should be
accessible to all, comprehensive, and technically perfect.
There is a cookies page in the faq notes. Can I get some suggestions for
how it could be improved?
http://jibbering.com/faq/faq_notes/cookies.html
The first obvious oddities are the naming convention:-
Get_Cookie
Then it looks like some typechecking in each function:-
if(typeof document.cookie == "string"){
That page mentions where ZoneAlarm changes document.cookie to
document.ignore.
If needed, I rather have a one-time test:-
var SUPPORTS_COOKIES = document.cookie == "string";
- and have that function to always return a string value:-
function getCookie(name){
if(!SUPPORTS_COOKIES) return "";
}
And about the coding strategy, it should carefully match the rfc.
http://www.faqs.org/rfcs/rfc2965.html
It is also worth mentioning HttpOnly cookie.
Garrett Smith
> Thomas 'PointedEars' Lahn wrote:
>> Dr J R Stockton wrote:
>>
>>> Garrett Smith posted:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Garrett Smith wrote:
>>>>>> FAQ server wrote:
>> -----------------------------------------------------------------------
>>>>>>> FAQ Topic - How can I see in javascript if a web browser
>>>>>>> accepts cookies?
[...]
> If needed, I rather have a one-time test:-
> var SUPPORTS_COOKIES = document.cookie == "string";
>
Whoops, how about:
typeof document.cookie == "string";
Thomas 'PointedEars' Lahn
> Garrett Smith wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Dr J R Stockton wrote:
>>>> Garrett Smith posted:
>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>> Garrett Smith wrote:
>>>>>>> FAQ server wrote:
>>> -----------------------------------------------------------------------
>>>>>>>> FAQ Topic - How can I see in javascript if a web browser
>>>>>>>> accepts cookies?
>
> [...]
>> If needed, I rather have a one-time test:-
>> var SUPPORTS_COOKIES = document.cookie == "string";
>>
>
> Whoops, how about:
> typeof document.cookie == "string";
How about not doing this at all? It is a property of a host object; even
if you can assign it a string, it does not need to yield "string" for
`typeof'. That said, the test is probably superfluous by now, and
potentially misleading.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Garrett Smith
> Garrett Smith wrote:
>
>> Garrett Smith wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Dr J R Stockton wrote:
>>>>> Garrett Smith posted:
>>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>> Garrett Smith wrote:
>>>>>>>> FAQ server wrote:
>>>> -----------------------------------------------------------------------
>>>>>>>>> FAQ Topic - How can I see in javascript if a web browser
>>>>>>>>> accepts cookies?
>> [...]
>>> If needed, I rather have a one-time test:-
>>> var SUPPORTS_COOKIES = document.cookie == "string";
>>>
>> Whoops, how about:
>> typeof document.cookie == "string";
>
> How about not doing this at all? It is a property of a host object; even
> if you can assign it a string, it does not need to yield "string" for
> `typeof'. That said, the test is probably superfluous by now, and
> potentially misleading.
>
Apparently, ZoneAlarm replaces document.cookie with document.ignore:-
if(typeof document.cookie == "string"){
with
if(typeof document.ignore == "string"){
document.cookie is specified to be a domstring. it could be expected to
be a string value.
The typecheck might help prevent an error, but I can't say I know about
ZoneAlarm or other firewalls, but it is worth considering preventing errors.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Garrett Smith wrote:
>>> Garrett Smith wrote:
>>>> If needed, I rather have a one-time test:-
>>>> var SUPPORTS_COOKIES = document.cookie == "string";
>>>
>>> Whoops, how about:
>>> typeof document.cookie == "string";
>>
>> How about not doing this at all? It is a property of a host object;
>> even if you can assign it a string, it does not need to yield "string"
>> for `typeof'. That said, the test is probably superfluous by now, and
>> potentially misleading.
>
> I haven't tried ZoneAlarm, so I can't say.
>
> Apparently, ZoneAlarm replaces document.cookie with document.ignore:-
Irrelevant.
> if(typeof document.cookie == "string"){
>
> with
> if(typeof document.ignore == "string"){
>
> document.cookie is specified to be a domstring.
It is not specified at all. The HTMLDocument interface of W3C DOM Level 2
HTML, of which we assume that it is implemented by the object referred to
by `document', has a `cookie' attribute of type DOMString, and the
ECMAScript Language Binding section of W3C DOM Level 2 HTML says that
objects that implement this interface should have a String-type property
named `cookie'.
> it could be expected to be a string value.
But should not. It is sufficient that it yields a string value on read
access and accepts one on write access.
> The typecheck might help prevent an error, but I can't say I know about
> ZoneAlarm or other firewalls, but it is worth considering preventing
> errors.
It is not. Everyone using (snake-oil) software borken like this deserve
what they get.
Dr J R Stockton
>, Sun, 20 Dec 2009 00:00:03, FAQ server <javas...@dotinternet.be>
posted:
>FAQ Topic - How can I see in javascript if a web browser
>accepts cookies?
>Write a cookie and read it back and check if it's the same.
What happens if cookies are enabled seems to be well enough specified;
and it may well be that the implementations all conform well enough with
the specification.
I don't know, however, whether the possible modes of non-operation are
well enough specified or consistently implemented - whether non-
operation is because of non-implementation or because of a disabling
setting.
It could be that document.cookie is always read by JavaScript as
undefined, null, false, or "".
It could be that document.cookie cannot be changed by JavaScript.
It could even be that an attempt to change it, or to read it, results in
a runtime error.
It could be that document.cookie behaves like document.doughnut.
It could be that cookie data sent by the server to the browser is
ignored.
It could be that cookie data is not sent to the server.
Any or all of those, and perhaps others, might happen; and the situation
might differ between first/second party and third party cookies.
To test reliably, one must consider all of the possibilities present or
omitted above, what the standards imply, and what real browsers actually
do.
The only really safe test must be to perform a complete circuit of a
cookie, and to see what happens.
Things have changed since FAQs were introduced.
For such topics, a link to the Wikipedia article should be given (after
checking the article for errors and correcting any found). Wiki
articles on popular topics are updated when required more reliably than
those on any "ordinary" Web site. The article probably will not answer
the FAQ question; but it will provide useful background.
Garrett Smith
>> , Sun, 20 Dec 2009 00:00:03, FAQ server <javas...@dotinternet.be>
> posted:
>
>
>
>
> Things have changed since FAQs were introduced.
>
> For such topics, a link to the Wikipedia article should be given (after
> checking the article for errors and correcting any found). Wiki
> articles on popular topics are updated when required more reliably than
> those on any "ordinary" Web site. The article probably will not answer
> the FAQ question; but it will provide useful background.
>
Wikipedia's cookie entry:
| To allow the user to see the cookies that are active with respect to a
| given page by typing javascript:alert(document.cookie) in the browser
| URL field. Some browsers incorporate a cookie manager for the user to
| see and selectively delete the cookies currently stored in the browser
Below, the entry shows that this is not a completely accurate statement
by explaining `HttpOnly` cookie, wheich cannot be accessed by script.
| The `HttpOnly` flag is not part of any standard, and is not
| implemented in all browsers. Note that there is currently no
| prevention of reading or writing the session cookie via an
| XMLHTTPRequest
XMLHTTPRequest is misspelled.
| The use of cookies may generate an inconsistency between the state of
| the client and the state as stored in the cookie. If the user acquires
| a cookie and then clicks the "Back" button of the browser, the state
| on the browser is generally not the same as before that acquisition.
The state of the browser or the state of the web application?
There is the suggestion for using `window.name` as an alternative to
cookies. I do not agree with that suggestion at all. The window.name is
not sent to the server and obviously fails cross-frame. The suggestion
for using cached javascript variables is more silliness.
David Mark
> Dr J R Stockton wrote:> In comp.lang.javascript message <4b2d690c$0$279$14726...@news.sunsite.dk
> >> , Sun, 20 Dec 2009 00:00:03, FAQ server <javascr...@dotinternet.be>
> > posted:
>
> [...]
>
>
>
> > Things have changed since FAQs were introduced.
>
> > For such topics, a link to the Wikipedia article should be given (after
> > checking the article for errors and correcting any found). Wiki
> > articles on popular topics are updated when required more reliably than
> > those on any "ordinary" Web site. The article probably will not answer
> > the FAQ question; but it will provide useful background.
>
> Wikipedia's cookie entry:
>
> | To allow the user to see the cookies that are active with respect to a
> | given page by typing javascript:alert(document.cookie) in the browser
> | URL field. Some browsers incorporate a cookie manager for the user to
> | see and selectively delete the cookies currently stored in the browser
>
Wikipedia is a joke when it comes to JS. After seeing the ridiculous
puff-pieces on crap like jQuery and Prototype, back in 2008, I created
an entry for My Library.
Various twits shouted it down as "irrelevant". LOL. It was relevant
then (obviously) and is certainly relevant today. They don't consider
blogs or newsgroups to be "real sources", but they can't seem to
specify what a real source is. Ajaxian? I just gave up on it as the
people I was arguing with clearly had no idea what I was talking about
(e.g. feature testing). Eventually they deleted it (and its "talk
page", so who knows how to re-ignite the debate).
They've got various lists of "JavaScript Libraries" sprinkled
throughout. So I added links to mine to a couple I found. Recently I
saw this edit entry:-
"lnk Dhtmlx, JXtension on presumption they're notable despite lack of
articles; remove My Library per Wikipedia:Articles for deletion/My
Library)"
Yeah, that makes sense. A year and a half old "frozen" transcript is
justification that My Library is irrelevant _today_. Yet, these other
two were added (what the hell are they?) on some unspecified
presumption of relevance (and no "articles" to back them up). What
sort of Rabbit Hole is this?
And why doesn't somebody add a Criticism section to jQuery's page? I
flagged it as reading like a commercial at one point, but then some
twit removed my comments. It's history according to the last person
to edit each page. :)
From the first Features entry:-
"DOM element selections using the cross-browser open source selector
engine Sizzle, a spin-off out of the jQuery project"
Cross-browser? It's not even cross-IE. And "Sizzle" is just the old
BS selector engine, which now defers to QSA in almost every browser
jQuery "supports". In other words, it's a commercial for an
irrelevant piece of junk. About the best they could say is that it's
been popular (and that popularity is now waning).
Dr J R Stockton
september.org>, Fri, 1 Jan 2010 20:04:32, Garrett Smith
<dhtmlk...@gmail.com> posted:
>Dr J R Stockton wrote:
>> In comp.lang.javascript message <4b2d690c$0$279$1472...@news.sunsite.dk
>>> , Sun, 20 Dec 2009 00:00:03, FAQ server <javas...@dotinternet.be>
>> posted:
>>
>[...]
>
>> Things have changed since FAQs were introduced.
>> For such topics, a link to the Wikipedia article should be given
>>(after
>> checking the article for errors and correcting any found). Wiki
>> articles on popular topics are updated when required more reliably than
>> those on any "ordinary" Web site. The article probably will not answer
>> the FAQ question; but it will provide useful background.
>>
>
>Wikipedia's cookie entry:
>
>| To allow the user to see the cookies that are active with respect to a
>| given page by typing javascript:alert(document.cookie) in the browser
>| URL field. Some browsers incorporate a cookie manager for the user to
>| see and selectively delete the cookies currently stored in the browser
>
>Below, the entry shows that this is not a completely accurate statement
>by explaining `HttpOnly` cookie, wheich cannot be accessed by script.
Many documents explain the general situation first, with exceptions or
additions treated later. It is normal practice, if too much initial
attention to detail will hamper initial understanding.
>| The `HttpOnly` flag is not part of any standard, and is not
>| implemented in all browsers. Note that there is currently no
>| prevention of reading or writing the session cookie via an
>| XMLHTTPRequest
>
>XMLHTTPRequest is misspelled.
Then correct it, if you know better. It does not appear mis-spelt to
me; do you mean that its use of capital letters does not match the real
thing? IMHO, as it is not in <code></code>, it is not intended as an
identifier. It should, therefore, read "XML HTTP request".
>| The use of cookies may generate an inconsistency between the state of
>| the client and the state as stored in the cookie. If the user acquires
>| a cookie and then clicks the "Back" button of the browser, the state
>| on the browser is generally not the same as before that acquisition.
>
>The state of the browser or the state of the web application?
>
>There is the suggestion for using `window.name` as an alternative to
>cookies. I do not agree with that suggestion at all. The window.name is
>not sent to the server and obviously fails cross-frame. The suggestion
>for using cached javascript variables is more silliness.
Then amend it. The matter can be discussed here first, to ensure
correctness.