Cookies in non-server pages?

Stephan Schulz · Jan 23, 2006

Hi all,

I'm fairly new to JavaScript, and couldn't find a way to solve the
following problem:

I've written an application in DHTML/JavaScript, for one because I
want to be able to offer access on the web, but primarily because it
was the easiest way for me to combine GUI and layout in a portable
manner.

In case you wonder, it is a character generator for pen-and-paper
roleplaying game (http://www.eprover.org/ROLESIM/chargen2.html -
German language, but code and comments are (mostly) English).

It is still preliminary, but works fine. However, the first time my
users used it, they immediately wanted to safe their characters for
later updates. I know that JavaScript has no direct access to the
local file system (and for good reasons), but we came up with the idea
of storing a character profile in a cookie.

My first test seems to work, but only when the page is actually served
via a web server. The more frequent use case is that the program is
run from a local file. In tat case, it seems that the cookie is not
set at all.

Is there any way around this problem (short of running a cooperating
webserver on each users computer)? Maybe it's just an issue with
setting the proper domain?

Thanks!

Bye,

Stephan

Thomas 'PointedEars' Lahn · Jan 23, 2006

Stephan said:
My first test seems to work, but only when the page is actually served
via a web server. The more frequent use case is that the program is
run from a local file. In tat case, it seems that the cookie is not
set at all.

Is there any way around this problem (short of running a cooperating
webserver on each users computer)? Maybe it's just an issue with
setting the proper domain?

Local files have no domain which is the reason why cookies do not work
reliably via the `file:' URI scheme. However, if it is a _program_ that
is _run_ from a local _file_, there is no reason why this program could
not obtain a file handle for accessing the local filesystem.

PointedEars

Stephan Schulz · Jan 23, 2006

Local files have no domain which is the reason why cookies do not work
reliably via the `file:' URI scheme.

Hummm...is there any way to make it work unreliably? For the online
version, it's important to make it work as widely as possible. For the
local copy, it's OK if I can make it run in Safari or Firefox (or,
preferably, both).

However, if it is a _program_ that
is _run_ from a local _file_, there is no reason why this program could
not obtain a file handle for accessing the local file system.

It's JavaScript, embedded in HTML. I consider it a program, but it is
not a stand-alone binary. It's executed by the interpreter of the
browser. If there are file-handling functions in JavaScript, they have
escaped me so far (which would not be a surprise...I' started writing
this thing 2 weeks ago or so, and it's my first JavaScript project).

Thanks anyways!

Bye,

Stephan

Thomas 'PointedEars' Lahn · Jan 25, 2006

Stephan said:
[...] Thomas 'PointedEars' Lahn said:

Local files have no domain which is the reason why cookies do not work
reliably via the `file:' URI scheme.

Click to expand...

Hummm...is there any way to make it work unreliably?

Perhaps you meant to ask "Is there any way to make it work reliably?" since
it already works unreliably

The answer would be: No, there is not. A
user agent may or may not support cookies for the `file:' URI scheme.

For the online version, it's important to make it work as widely as
possible. For the local copy, it's OK if I can make it run in Safari
or Firefox (or, preferably, both).

Try this:

<body>
<script type="text/javascript">
document.write('document.cookie = ' + document.cookie + "<br>\n");
document.write('document.cookie = ' + navigator.userAgent);
var d = new Date();
document.cookie = "foo=" + d.toGMTString()
+ "; expires="
+ new Date(d.getTime() + 24*3600000).toGMTString()
+ "; path=/home/scripts/test"; // modify to fit your needs
</script>
</body>

Surprising to me, it appears to work reliably in

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060110
Debian/1.5.dfsg-4 Firefox/1.5 Mnenhy/0.7.3.0

and

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051007
Debian/1.7.12-1

It is even possible to specify the `path' component to allow `file://'
cookies to work between files in different directories. It is required
that the `domain' component is omitted, i.e. `domain=' or
`domain=localhost' does not work. Note that those cookies will be set
with domain `scheme:file', so if you look for the appropriate cookie rule
(which may have been set by having the checkbox in the cookie message box
checked), you have to look for this.

Cookies for `file://' resources do not appear to work in

Mozilla/5.0 (compatible; Konqueror/3.5; Linux 2.6.14.4-20051220.153223+0100;
X11; i686; de, en_US) KHTML/3.5.0 (like Gecko) (Debian package 4:3.5.0-3)

which is why I assume they will also not work in Safari (both use KHTML as
layout engine and KJS as script engine): the cookies can be set there (or
so it seems) but they cannot be retrieved later.

It's JavaScript, embedded in HTML. I consider it a program, but it is
not a stand-alone binary. It's executed by the interpreter of the
browser. If there are file-handling functions in JavaScript, they have
escaped me so far (which would not be a surprise...I' started writing
this thing 2 weeks ago or so, and it's my first JavaScript project).

If you do not want to use cookies (with the restrictions described above),
you will have to use at least UA-specific host objects. For Gecko-based
browsers these would be XPCOM file objects available in privileged script;
for IE, it would be the FileSystemObject ActiveX/COM object.

<URL:http://xulplanet.com/references/xpcomref/group_Files.html>
<URL:http://msdn.microsoft.com/library/en-us/script56/html/af4423b2-4ee8-41d6-a704-49926cd4d2e8.asp>

As for Safari, I am afraid that the KHTML DOM does not appear to provide for
such an object:

<http://developer.kde.org/documentation/library/3.4-api/khtml/html/index.html>

But it is entirely possible that I overlooked something.

PointedEars

Stephan Schulz · Jan 25, 2006

Stephan said:
Stephan said:

[...] Thomas 'PointedEars' Lahn said:

Local files have no domain which is the reason why cookies do not work
reliably via the `file:' URI scheme.

Click to expand...

Hummm...is there any way to make it work unreliably?

Click to expand...

Perhaps you meant to ask "Is there any way to make it work reliably?" since
it already works unreliably

Hmm, for me the naive way reliably failed to work ;-)

The answer would be: No, there is not. A
user agent may or may not support cookies for the `file:' URI scheme.

Try this:

<body>
<script type="text/javascript">
document.write('document.cookie = ' + document.cookie + "<br>\n");
document.write('document.cookie = ' + navigator.userAgent);
var d = new Date();
document.cookie = "foo=" + d.toGMTString()
+ "; expires="
+ new Date(d.getTime() + 24*3600000).toGMTString()
+ "; path=/home/scripts/test"; // modify to fit your needs
</script>
</body>

Surprising to me, it appears to work reliably in

[...]

That's very useful, thanks a lot!

If you do not want to use cookies (with the restrictions described above),
you will have to use at least UA-specific host objects. For Gecko-based
browsers these would be XPCOM file objects available in privileged script;
for IE, it would be the FileSystemObject ActiveX/COM object.

[...]

Ok. I'll stick with the cookie method that I can probaly make to work
portably for FireFox and for the web version.

Bye,

Stephan

Thomas 'PointedEars' Lahn · Jan 25, 2006

Stephan said:
[...] Thomas 'PointedEars' Lahn said:

Stephan said:

For the online version, it's important to make it work as widely as
possible. For the local copy, it's OK if I can make it run in Safari
or Firefox (or, preferably, both).

Click to expand...

Try this:

<body>
<script type="text/javascript">
document.write('document.cookie = ' + document.cookie + "<br>\n");
document.write('document.cookie = ' + navigator.userAgent); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
var d = new Date();
document.cookie = "foo=" + d.toGMTString()
+ "; expires="
+ new Date(d.getTime() + 24*3600000).toGMTString()
+ "; path=/home/scripts/test"; // modify to fit your needs
</script>
</body>

Surprising to me, it appears to work reliably in [...]

Click to expand...

^^
[...]

That's very useful, thanks a lot!

D'oh. Did I really post the unrevised version? Use this instead:

<body>
<script type="text/javascript">
document.write('document.cookie = ' + document.cookie + "<br>\n"
+ 'navigator.userAgent = ' + navigator.userAgent);
var d = new Date();
document.cookie = "foo=" + d.toGMTString()
+ "; expires="
+ new Date(d.getTime() + 24*3600000).toGMTString()
+ "; path=/home/scripts/test"; // modify to fit your needs
</script>
</body>

You're welcome, anyway

Regards,
PointedEars

Dr John Stockton · Jan 26, 2006

JRS: In article <[email protected]>, dated Wed, 25 Jan
2006 01:26:57 remote, seen in Thomas

'PointedEars' Lahn said:
document.cookie = "foo=" + d.toGMTString()
+ "; expires="
+ new Date(d.getTime() + 24*3600000).toGMTString()
+ "; path=/home/scripts/test"; // modify to fit your needs

If users of that announce a 1-day lifetime, they should be prepared for
complaints at the end of October. Using d.setDate(d.getDate()+1))
would not be significantly slower.

Why do you choose to recommend use of a property which has been
deprecated since 1998 or earlier (or has it been de-deprecated in
acknowledgement of the fact that in javascript (by specification) and in
most computers the time behaves more like GMT than UTC)? You should
read ECMA-262, backwards.

Thomas 'PointedEars' Lahn · Jan 26, 2006

Dr said:
[...] Thomas 'PointedEars' Lahn [...] posted :

document.cookie = "foo=" + d.toGMTString() ^
+ "; expires="
+ new Date(d.getTime() + 24*3600000).toGMTString()
+ "; path=/home/scripts/test"; // modify to fit your needs

Click to expand...

If users of that announce a 1-day lifetime, they should be prepared for
complaints at the end of October. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Using d.setDate(d.getDate()+1)) would not be significantly slower.

Nice to know. Why do you assume it was my intention to let the cookie
expire 1 day later?

Why do you choose to recommend use of a property which has been
deprecated since 1998 or earlier (or has it been de-deprecated in
acknowledgement of the fact that in javascript (by specification) and in
most computers the time behaves more like GMT than UTC)?

Because this is but an example for a cookie that will not expire by the end
of the session?

You should read ECMA-262, backwards.

Everybody should; starting with you, as you seem to have too much free time
on your hands, making wild assumptions about the most unimportant details
just to comment anything.

PointedEars

Randy Webb · Jan 27, 2006

Thomas 'PointedEars' Lahn said the following on 1/26/2006 2:54 PM:

Dr said:
Dr said:

[...] Thomas 'PointedEars' Lahn [...] posted :

document.cookie = "foo=" + d.toGMTString() ^
+ "; expires="
+ new Date(d.getTime() + 24*3600000).toGMTString()
+ "; path=/home/scripts/test"; // modify to fit your needs

Click to expand...

If users of that announce a 1-day lifetime, they should be prepared for
complaints at the end of October.

Click to expand...

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

As well as in the Spring Time.

Nice to know. Why do you assume it was my intention to let the cookie
expire 1 day later?

Simple Math, and common sense, my dear Watson. 24*3600000 = 86400000
which divided by 1000 gives 86,400 seconds which is the number most
people incorrectly use to add 1 day to a Date Object. And since you
appear to be attempting to add 1 day to the date then the common sense
answer is that you are attempting to expire the cookie "1 day later".

Because this is but an example for a cookie that will not expire by the end
of the session?

One should endeavor to provide the best code possible, not just "an
example" that is fraught with problems.

And, it *will* expire before the end of the session if the session lasts
more than 24 hours. Note that I did not say exceeds more than 1 day.

Everybody should;

Yes, even if for nothing more than some boring reading.

starting with you, as you seem to have too much free time
on your hands, making wild assumptions about the most unimportant details
just to comment anything.

Coming from you, that is plain hilarious.

PointedEars

Notice the improper signature that you asked, just yesterday, to not be
quoted? Please either properly delimit it or stop claiming it as a
signature.

Dr John Stockton · Jan 27, 2006

JRS: In article <[email protected]>, dated Thu, 26 Jan
2006 20:54:07 remote, seen in Thomas

'PointedEars' Lahn said:
Dr said:

[...] Thomas 'PointedEars' Lahn [...] posted :

document.cookie = "foo=" + d.toGMTString() ^
+ "; expires="
+ new Date(d.getTime() + 24*3600000).toGMTString()
+ "; path=/home/scripts/test"; // modify to fit your needs

Click to expand...

If users of that announce a 1-day lifetime, they should be prepared for
complaints at the end of October. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Using d.setDate(d.getDate()+1)) would not be significantly slower.

Click to expand...

Nice to know. Why do you assume it was my intention to let the cookie
expire 1 day later?

I assumed nothing about your intention; I was referring to what the
unwitting consumer of your flawed advice might think your code eas good
for.

Because this is but an example for a cookie that will not expire by the end
of the session?

So why use a deprecated method when a non-deprecated one will do the
job? It's not setting a good example.

Everybody should; starting with you, as you seem to have too much free time
on your hands, making wild assumptions about the most unimportant details
just to comment anything.

Now you're being puerile - or is it early Alzheimer's, or just your true
nature showing?

Dr John Stockton · Jan 28, 2006

JRS: In article <[email protected]>, dated Fri, 27 Jan
2006 11:29:32 remote, seen in Randy Webb

Dr said:
Thomas 'PointedEars' Lahn said the following on 1/26/2006 2:54 PM:

Dr said:

[...] Thomas 'PointedEars' Lahn [...] posted :

document.cookie = "foo=" + d.toGMTString() ^
+ "; expires="
+ new Date(d.getTime() + 24*3600000).toGMTString()
+ "; path=/home/scripts/test"; // modify to fit your needs
If users of that announce a 1-day lifetime, they should be prepared for
complaints at the end of October.

Click to expand...

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Click to expand...

As well as in the Spring Time.

The end of October is also Spring; don't be parochial.

However, it's much more likely that an end-user will complain of
apparently premature expiry than of apparently belated expiry. So,
while there may be a few complaints in March/April, they'll
predominantly have been sent in Autumn, whatever season they're received
in.

MDX pages not rendering in Gatsby.js	0	Oct 25, 2023
What is AI programming to us non-bigtech programmers?	4	Jun 1, 2023
Problem with a login script, SESSION user rights and put this together so it works with the other pages and MySQL. Code examples.	2	May 5, 2023
How to loop through all the other pages in a pdf using python	3	May 16, 2023
Python client/server that reads HTML body from server	1	Apr 12, 2023
cookies or storage or ..?	5	Jul 16, 2009
cookies set in php, read in javascript	5	Nov 2, 2009
cookies in HTA	1	Feb 25, 2008

Cookies in non-server pages?

Stephan Schulz

Thomas 'PointedEars' Lahn

Stephan Schulz

Thomas 'PointedEars' Lahn

Stephan Schulz

Thomas 'PointedEars' Lahn

Dr John Stockton

Thomas 'PointedEars' Lahn

Randy Webb

Dr John Stockton

Dr John Stockton

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads