Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Cookies in non-server pages?

Reply
Thread Tools

Cookies in non-server pages?

 
 
Stephan Schulz
Guest
Posts: n/a
 
      01-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

--
-------------------------- It can be done! ---------------------------------
Please email me as http://www.velocityreviews.com/forums/(E-Mail Removed) (Stephan Schulz)
----------------------------------------------------------------------------
 
Reply With Quote
 
 
 
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      01-23-2006
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
 
Reply With Quote
 
 
 
 
Stephan Schulz
Guest
Posts: n/a
 
      01-23-2006
In article <(E-Mail Removed)>, 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 (E-Mail Removed) (Stephan Schulz)
----------------------------------------------------------------------------
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      01-25-2006
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. 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
 
Reply With Quote
 
Stephan Schulz
Guest
Posts: n/a
 
      01-25-2006
In article <(E-Mail Removed)>, 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 (E-Mail Removed) (Stephan Schulz)
----------------------------------------------------------------------------
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      01-25-2006
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
 
Reply With Quote
 
Dr John Stockton
Guest
Posts: n/a
 
      01-26-2006
JRS: In article <(E-Mail Removed)>, dated Wed, 25 Jan
2006 01:26:57 remote, seen in news:comp.lang.javascript, Thomas
'PointedEars' Lahn <(E-Mail Removed)> 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.
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      01-26-2006
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
 
Reply With Quote
 
Randy Webb
Guest
Posts: n/a
 
      01-27-2006
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/
 
Reply With Quote
 
Dr John Stockton
Guest
Posts: n/a
 
      01-27-2006
JRS: In article <(E-Mail Removed)>, dated Thu, 26 Jan
2006 20:54:07 remote, seen in news:comp.lang.javascript, Thomas
'PointedEars' Lahn <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Give Request.Cookies and Response.Cookies is there any reason to use another method to use cookies? _Who ASP .Net 7 09-18-2008 07:49 PM
What's the proper way of reading cookies? Request.Cookies("mycook") doesnt work user ASP .Net 3 03-31-2007 01:53 PM
Response.Cookies vs Request.Cookies Alex Nitulescu ASP .Net 1 02-03-2005 09:43 AM
Persistent Cookies vs. session cookies Andy Fish Java 3 11-06-2003 10:44 AM
Good Cookies bad Cookies? AK Computer Support 23 10-26-2003 05:20 AM



Advertisments