Cookies in non-server pages?

Discussion in 'Javascript' started by Stephan Schulz, Jan 23, 2006.

  1. 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 (Stephan Schulz)
    ----------------------------------------------------------------------------
    Stephan Schulz, Jan 23, 2006
    #1
    1. Advertising

  2. 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
    Thomas 'PointedEars' Lahn, Jan 23, 2006
    #2
    1. Advertising

  3. In article <>, 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 (Stephan Schulz)
    ----------------------------------------------------------------------------
    Stephan Schulz, Jan 23, 2006
    #3
  4. 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
    Thomas 'PointedEars' Lahn, Jan 25, 2006
    #4
  5. In article <>, 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 (Stephan Schulz)
    ----------------------------------------------------------------------------
    Stephan Schulz, Jan 25, 2006
    #5
  6. 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
    Thomas 'PointedEars' Lahn, Jan 25, 2006
    #6
  7. JRS: In article <>, dated Wed, 25 Jan
    2006 01:26:57 remote, seen in news:comp.lang.javascript, 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.

    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.
    Dr John Stockton, Jan 26, 2006
    #7
  8. 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
    Thomas 'PointedEars' Lahn, Jan 26, 2006
    #8
  9. Stephan Schulz

    Randy Webb Guest

    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/
    Randy Webb, Jan 27, 2006
    #9
  10. JRS: In article <>, dated Thu, 26 Jan
    2006 20:54:07 remote, seen in news:comp.lang.javascript, Thomas
    'PointedEars' Lahn <> 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, Jan 27, 2006
    #10
  11. JRS: In article <>, dated Fri, 27 Jan
    2006 11:29:32 remote, seen in news:comp.lang.javascript, Randy Webb
    <> 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.
    Dr John Stockton, Jan 28, 2006
    #11
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alex Nitulescu

    Response.Cookies vs Request.Cookies

    Alex Nitulescu, Feb 3, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    8,459
    Hans Kesting
    Feb 3, 2005
  2. Replies:
    1
    Views:
    3,190
    PeterKellner
    May 16, 2006
  3. archana
    Replies:
    1
    Views:
    500
  4. _Who
    Replies:
    7
    Views:
    2,637
  5. bb
    Replies:
    0
    Views:
    547
Loading...

Share This Page