Cookies in non-server pages?

[Stephan Schulz]

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

--
-------------------------- It can be done! ---------------------------------
Please email me as sc****@eprover.org (Stephan Schulz)
----------------------------------------------------------------------------

[Thomas 'PointedEars' Lahn]

Stephan Schulz wrote:

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]

In article <43****************@PointedEars.de>, Thomas 'PointedEars' Lahn wrote:

Stephan Schulz wrote:

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 that 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.

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

--
-------------------------- It can be done! ---------------------------------
Please email me as sc****@eprover.org (Stephan Schulz)
----------------------------------------------------------------------------

[Thomas 'PointedEars' Lahn]

Stephan Schulz wrote:

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

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?

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.

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).

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]

In article <11****************@PointedEars.de>, Thomas 'PointedEars' Lahn wrote:

Stephan Schulz wrote:

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

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?

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.

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

[...]

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

--
-------------------------- It can be done! ---------------------------------
Please email me as sc****@eprover.org (Stephan Schulz)
----------------------------------------------------------------------------

[Thomas 'PointedEars' Lahn]

Stephan Schulz wrote:

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

Stephan Schulz wrote:

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 [...]

^^ [...]

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]

JRS: In article <11****************@PointedEars.de>, dated Wed, 25 Jan
2006 01:26:57 remote, seen in news:comp.lang.javascript, Thomas
'PointedEars' Lahn <Po*********@web.de> 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. 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.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Thomas 'PointedEars' Lahn]

Dr John Stockton wrote:

[...] 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.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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]

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

Dr John Stockton wrote:

[...] 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.

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

As well as in the Spring Time.

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?

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".

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?

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.

You should read ECMA-262, backwards.

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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Dr John Stockton]

JRS: In article <11*****************@PointedEars.de>, dated Thu, 26 Jan
2006 20:54:07 remote, seen in news:comp.lang.javascript, Thomas
'PointedEars' Lahn <Po*********@web.de> posted :

Dr John Stockton wrote:

[...] 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.

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

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?

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.

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?

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

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.

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

--
© John Stockton, Surrey, UK. ??*@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.

[Dr John Stockton]

JRS: In article <Vo********************@comcast.com>, dated Fri, 27 Jan
2006 11:29:32 remote, seen in news:comp.lang.javascript, Randy Webb
<Hi************@aol.com> posted :

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

Dr John Stockton wrote:

[...] 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.

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

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.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.