FAQ Topic - How can I see in javascript if a web browser accepts cookies?

F

FAQ server

-----------------------------------------------------------------------
FAQ Topic - How can I see in javascript if a web browser accepts cookies?
-----------------------------------------------------------------------

Writing a cookie, reading it back and checking if it's the same.

http://www.w3schools.com/js/js_cookies.asp

Additional Notes:

http://www.jibbering.com/faq/faq_notes/cookies.html


===
Postings such as this are automatically sent once a day. Their
goal is to answer repeated questions, and to offer the content to
the community for continuous evaluation/improvement. The complete
comp.lang.javascript FAQ is at http://www.jibbering.com/faq/.
The FAQ workers are a group of volunteers.
 
E

Evertjan.

Andrew Poulos wrote on 11 dec 2006 in comp.lang.javascript:
Can't you just check window.navigator.cookieEnabled?

Are there any browsers not implementing this? [ie and ff seem ok]
 
R

Richard Cornford

Evertjan. said:
Andrew Poulos wrote on 11 dec 2006 in comp.lang.javascript:
Can't you just check window.navigator.cookieEnabled?

Are there any browsers not implementing this? [ie and ff seem ok]

It would not matter is there were not as that test doesn't take into
account the actions of content inserting/re-writing proxies which may
re-write the code that references cookies so that it does not (i.e.
change all occurrences of the character sequence 'cookie' into
something else).

Richard.
 
E

Evertjan.

Richard Cornford wrote on 11 dec 2006 in comp.lang.javascript:
Evertjan. said:
Andrew Poulos wrote on 11 dec 2006 in comp.lang.javascript:
Writing a cookie, reading it back and checking if it's the same.

Can't you just check window.navigator.cookieEnabled?

Are there any browsers not implementing this? [ie and ff seem ok]

It would not matter is there were not as that test doesn't take into
account the actions of content inserting/re-writing proxies which may
re-write the code that references cookies so that it does not (i.e.
change all occurrences of the character sequence 'cookie' into
something else).

eh?
 
R

Richard Cornford

E

Evertjan.

Richard Cornford wrote on 11 dec 2006 in comp.lang.javascript:
Evertjan. said:
Richard said:
Evertjan. wrote:
Andrew Poulos wrote:
Can't you just check window.navigator.cookieEnabled?

Are there any browsers not implementing this? [ie and ff seem ok]

It would not matter is there were not as that test doesn't take into
^^
Should be 'if'

I read there:
ZoneAlarm is capable of inserting text into, and re-writing, incoming
HTML pages. It might be that it is preventing client side cookies by
re-writing any occurrences of the identifier 'cookie' that it find
within script sections or pages. That would leave server created HTTP
cookies unaffected (Ebay) and eliminate all client-side JavaScript
cookies.

Well yes, but that does not mean we should programme for any clientside
irregularity.

Cookie writing/reading sequence will not test for cookie cleaning after
browser shutdown, or show the memory-cookie-expire ability either.

====================

I propose window.navigator.cookieEnabled is worth of inserting in the
FAQ.
 
M

Michael Winter

Evertjan. said:
I read there:

Well yes, but that does not mean we should programme for any
clientside irregularity.

But surely one should make the effort for a known and not uncommon
possibility, especially when it takes little effort.
Cookie writing/reading sequence will not test for cookie cleaning
after browser shutdown, or show the memory-cookie-expire ability
either.

No method can prove the former - without server-side assistance and
expecting the user to close all browser instances. The latter can be
easily proved: create a cookie (session or future-dated, it doesn't
matter) then reassign that cookie with a date in the past. If the cookie
can be read after the first assignment but not after the second, then it
is reasonable to conclude that the user agent will not send expired
cookies. This approach is easily included while testing the property.
I propose window.navigator.cookieEnabled is worth of inserting in the
FAQ.

Opposed. It is no more reliable (and possibly less so).

Mike
 
E

Evertjan.

Michael Winter wrote on 11 dec 2006 in comp.lang.javascript:
But surely one should make the effort for a known and not uncommon
possibility, especially when it takes little effort.


No method can prove the former - without server-side assistance and
expecting the user to close all browser instances. The latter can be
easily proved: create a cookie (session or future-dated, it doesn't
matter) then reassign that cookie with a date in the past. If the
cookie can be read after the first assignment but not after the
second, then it is reasonable to conclude that the user agent will not
send expired cookies. This approach is easily included while testing
the property.

We were not discussing what can be eaily done, but what to put in the
FAQ.

Do we put your solution in the FAQ, and then how?
Opposed. It is no more reliable

That is no reason not to put it in the FAQ.

It is an easy solution, much shorter than a whole function:

if (window.navigator.cookieEnabled) {...}
(and possibly less so).

Could be, but if so, we should determine that first.
 
M

Michael Winter

Evertjan. said:
Michael Winter wrote on 11 dec 2006 in comp.lang.javascript:
[snip]
... create a cookie (session or future-dated, it doesn't matter)
then reassign that cookie with a date in the past. If the cookie
can be read after the first assignment but not after the second,
then it is reasonable to conclude that the user agent will not send
expired cookies. This approach is easily included while testing the
property.
[snip]

Do we put your solution in the FAQ, and then how?

I don't know. It looks a little messy as a single function, but can look
rather intimidating as a collection.

Below is collection of cookie-related methods that I wrote a while ago.
The makeAge method isn't used by the isSupported method.

var Session = function () {
var supported = false;

return {
get: function (name) {
var match = new RegExp('(^|;)\\s*' + name
+ '\\s*=\\s*([^\\s;]+)').exec(document.cookie);

return match ? match[2] : null;
},
set: function (name, value, maxAge, path, domain) {
var cookie = name + '=' + value;

if (maxAge !== 0) {
var expires = new Date();

expires.setUTCSeconds(maxAge
+ expires.getUTCSeconds());
cookie += ';expires=' + expires.toGMTString();
}
if (path) cookie += ';path=' + path;
if (domain) cookie += ';domain=' + domain;
document.cookie = cookie;
},
remove: function (name, path, domain) {
this.set(name, 'deleted', -1, path, domain);
},
isSupported: function () {
if (typeof document.cookie == 'string') {
var name = 'test',
value = 'foobar';

while (this.get(name) != null) name += '-' + name;
this.set(name, value, 30);
if ((this.get(name) == value)
&& (this.get('expires') == null)) {
this.remove(name);
supported = (this.get(name) == null);
}
}
this.isSupported = function () {return supported;};
return supported;
},
makeAge: function (days, hours, minutes, seconds) {
return ((days * 24 + (+hours || 0)) * 60
+ (+minutes || 0)) * 60 + (+seconds || 0);
}
};
}();

The age value in the test is arbitrary, really. A value of 2 should
suffice, but a larger number makes no difference. An indication of
success requires the data to be deleted, anyway.
That is no reason not to put it in the FAQ.

It's certainly one reason.
It is an easy solution, much shorter than a whole function:

Is the property guaranteed? Does the property represent client-side
state management in general, or specifically that the document.cookie
property is usable? The former doesn't need to imply the latter; the
former is potentially useful information on its own. Given the nature of
the property, those are not easy questions to answer accurately.

[snip]
Could be, but if so, we should determine that first.

Richard already presented one reason why it definitely is, though I was
leaning more towards the existence of the property itself. Proving that
to any degree of certainty is impractical, as you should well know.

Mike
 
D

Dr J R Stockton

In comp.lang.javascript message
Wed said:
expires.setUTCSeconds(maxAge
+ expires.getUTCSeconds());

Those Methods require mod-60 arithmetic; they don't *need* (but might
cause) Y-M-D handling.

But expires.setTime(maxAge*1000 + expires.getTime());
does not.

The improvement will be insignificant (the preceding New Date() will
tale longer!).
 
M

Michael Winter

Dr J R Stockton wrote:

[snip]
Those Methods [get/setUTCSeconds] require mod-60 arithmetic; they
don't *need* (but might cause) Y-M-D handling.

But expires.setTime(maxAge*1000 + expires.getTime()); does not.

True. Thanks.

[snip]


Different subject: Firefox 2.0 objects to the leading zero in "08" on
line 145 of <http://www.merlyn.demon.co.uk/js-date1.htm>. This is within
the TryToUTC function declaration. I think you have other occurrences of
leading zeros in numeric literals in other documents. An initial zero
must be followed by something other than a digit.

The table at the end of "Resolutions of new Date()"
<http://www.merlyn.demon.co.uk/js-dates.htm#Ress> is positioned oddly to
the right causing a horizontal scrollbar. Again, in Firefox.

Mike
 
D

Dr J R Stockton

In comp.lang.javascript message
Thu said:
Different subject: Firefox 2.0 objects to the leading zero in "08" on
line 145 of <http://www.merlyn.demon.co.uk/js-date1.htm>. This is
within the TryToUTC function declaration. I think you have other
occurrences of leading zeros in numeric literals in other documents. An
initial zero must be followed by something other than a digit.

That's horrible; but it does seem to be in ECMA-262. Languages should
be written in Europe, where we have millennia of experience of the task.
It's not easy to locate all of those zeroes with available tools; but
I've found quite a few and fixed them. If you see any more ...

The table at the end of "Resolutions of new Date()" <http://www.merlyn.
demon.co.uk/js-dates.htm#Ress> is positioned oddly to the right causing
a horizontal scrollbar. Again, in Firefox.

I see no obvious reason. But if any FireFox expert can offer an
IE-compatible fix, I can install it. (The table should not in principle
be at the end of the section; it should be immediately after the code
box).

Thanks.

==

<URL:http://www.merlyn.demon.co.uk/js-misc1.htm#Cash> has, under "Ways
of Giving Change", a demonstration of cacheing in a recursive algorithm.
 
R

Randy Webb

Dr J R Stockton said the following on 12/14/2006 3:55 PM:
In comp.lang.javascript message


That's horrible; but it does seem to be in ECMA-262. Languages should
be written in Europe, where we have millennia of experience of the task.

Does your stupidity know *any* bounds at all?
 
E

Evertjan.

Randy Webb wrote on 15 dec 2006 in comp.lang.javascript:
Does your stupidity know *any* bounds at all?

No, Randy, our European endless stupidity is only surpassed by the American
counterpart.

Imagine the dullness of a world without stupidity. One would have to resort
to firearms to get rid of frustration.
 
R

Randy Webb

Evertjan. said the following on 12/15/2006 3:56 AM:
Randy Webb wrote on 15 dec 2006 in comp.lang.javascript:


No, Randy, our European endless stupidity is only surpassed by the American
counterpart.

Let's see here. Europe has had millennia of experience writing languages
yet there are how many different languages spoken in Europe? In endless
centuries they haven't come up with a single language yet Americans are
stupid yet they have one single language. How intuitive....

And no less, to say that the European Computer Manufacturers Association
language specification should be written in Europe is "intelligent"?
 
P

Peter Michaux

Andrew said:
Can't you just check window.navigator.cookieEnabled?

Aren't the properties of the navigator object completely spoofable? And
aren't browser makers free to do what they want with and lie completely
with the navigator object (and i suppose all other objects)? Or is it
just the userAgent property that they lie with?

Peter
 
R

Richard Cornford

Peter said:
Andrew Poulos wrote:

Aren't the properties of the navigator object completely spoofable?

Yes, but it depends on what you mean by that.
And aren't browser makers free to do what they want with and lie
completely with the navigator object (and i suppose all other objects)?

Yes, but why should they? There would be little to be gained from
setting - cookieEnabled - to true when cookies were not enabled or to
false when they were. The issue with - cookieEnabled - is that the
browser itself is not the final arbiter of a script's ability to read
and write cookies, so what the browser thinks it can do is not
necessarily the same as what can be done.
Or is it
just the userAgent property that they lie with?

The browser identification and version properties may be spoofing other
browser for practical reasons. The - userAgent - property is intended
to reflect the HTTP user agent header value, and in all cases I am
aware of it does. However, the HTTP 1.1 user agent header is not
specified as being a source of information, so it should not be treated
as one, and an object property that reflects a header that is not
specified as a source of information should then also not be treated as
a source of information. There can be no lie where there is no
information.

Richard.
 
V

VK

Peter said:
Aren't the properties of the navigator object completely spoofable?

cookieEnabled is read-only property. Or you mean someone has disabled
cookies but hacked the engine to report cookieEnabled == true ? :)
Also do not mix "feature detection" and "browser sniffing". The second
is spoofed over userAgent string left and right. My belowed case up to
date is of course Safari. (Some people do still believe that it is a
browser and not an Apple's practical joke - for them I'm reminding this
all times the best spoofing pearl: "...MSIE; Microsoft Internet
Explorer like Gecko".)

There are two very different types of cookies: 1) persistent cookies
and 2) session cookies.

Persistent cookies are the ones being stored client-side in
%system%Cookies folder (or equivalent). They remain - so can be read
back - until their expiration date or until manually removed.

Session cookies are not being stored in file: they exist only in the
computer memory and they disappear right after the current session:
thus after the last running instance of the browser is closed.

This way write/read back check can reliable tell only one thing: if
session cookies are enabled. This is true for 99% of cases so no big
use to check it really: but of course it doesn't make any harm.

At the same time persistent cookies can be very well disabled for given
domain depending on user preferences (block all cookies, block cookies
w/o P3P policies file etc.)

navigator.cookieEnabled checks if *persistent cookies are enabled* -
but it doesn't check for session cookies.

It is technically possible to have a system with session cookies
disabled but persistent cookies enabled: but such system has to be
handcrafted then, as I don't know of a way to achieve it by the
standard privacy settings.

To summarize:

If only session cookies are needed (thus you don't care about the data
after the session's end), then the old write/read trick can be used.

For any other purposes navigator.cookieEnabled check has to be used.
 
V

VK

VK said:
If only session cookies are needed (thus you don't care about the data
after the session's end), then the old write/read trick can be used.

For any other purposes navigator.cookieEnabled check has to be used.

To protect the reputation of the old FAQ version: :)

navigator.cookieEnabled check couldn't be suggested in the previous
version, because this property originally was IE-only.

As a universal method (still in use on many servers as
script-independent) is indeed write cookie / read it back. A very
important part was missing though in the FAQ: "write cookie on one
page, read cookie from *another* page". Only this way you can tell if a
web browser accepts cookies *for the given domain*, and this is the
question one really may want to know. An abstract "if a web browser
accepts cookies" has not much of sense but can be left for readability.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,020
Latest member
GenesisGai

Latest Threads

Top