cookie on browser but not on server

[neerolyte]

how would i go about setting a cookie in javascript that can be read in
javascript on the next page load, but will NOT be passed to the server?

[Steve van Dongen]

On Tue, 6 Jan 2004 16:37:40 +1100, "neerolyte"
<ne*******@nets pace.nOsPaM.net .au> wrote:

how would i go about setting a cookie in javascript that can be read in
javascript on the next page load, but will NOT be passed to the server?

Cookies are always sent to the server.

Regards,
Steve

[kaeli]

In article <bt**********@o tis.netspace.ne t.au>,
ne*******@netsp ace.nOsPaM.net. au enlightened us with...

how would i go about setting a cookie in javascript that can be read in
javascript on the next page load, but will NOT be passed to the server?

Don't use cookies. They are always stored on the server.
You could pass the parameter via the URL and read it in with javascript
if the pages are sequential.

--
--
~kaeli~
In democracy your vote counts. In feudalism your count votes.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Guido Wesdorp]

kaeli wrote:

You could pass the parameter via the URL and read it in with javascript
if the pages are sequential.

Or even better: store it on the window object, that will remain in tact
between pages, and afaik it's possible to read it from another page (I
assume it should be from the same domain or so) later on.

Cheers,

Guido

[neerolyte]

How do I use the window object?
I did this as a test:

<script language="JavaS cript">
document.write( window.myVar);
window.myVar = "this is stored?";
document.write( window.myVar);
</script>

the output is ALLWAYS "undefinedt his is stored?"
"Guido Wesdorp" <gu***@infrae.c om> wrote in message
news:3F******** ******@infrae.c om...

kaeli wrote:

You could pass the parameter via the URL and read it in with javascript
if the pages are sequential.

Or even better: store it on the window object, that will remain in tact
between pages, and afaik it's possible to read it from another page (I
assume it should be from the same domain or so) later on.

Cheers,

Guido

[neerolyte]

> Don't use cookies. They are always stored on the server.
they are stored in the browser!

You could pass the parameter via the URL and read it in with javascript
if the pages are sequential.

passing the parameter via the URL is still passing it to the server, the
problem is that the variable must not pass through the internet.

[Laurent Bugnion, GalaSoft]

Hi,

Guido Wesdorp wrote:

kaeli wrote:

You could pass the parameter via the URL and read it in with
javascript if the pages are sequential.

Or even better: store it on the window object, that will remain in tact
between pages, and afaik it's possible to read it from another page (I
assume it should be from the same domain or so) later on.

Cheers,

Guido

The instance of the Window object corresponding to the current
window/frame is renitialized every time that the page is loaded. There
is no persistence.

If you want persistence using a Window object, you must use frames, and
store the variables in the frameset. For example:

top.myVar = "Blabla";

Since the top frameset is not reloaded when you switch frame, the
variable won't be erased.

Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
Private/Malaysia: http://mypage.bluewin.ch/lbugnion
Support children in Calcutta: http://www.calcutta-espoir.ch

[kaeli]

In article <bt**********@o tis.netspace.ne t.au>,
ne*******@netsp ace.nOsPaM.net. au enlightened us with...

Don't use cookies. They are always stored on the server.

they are stored in the browser!

You could pass the parameter via the URL and read it in with javascript
if the pages are sequential.

passing the parameter via the URL is still passing it to the server, the
problem is that the variable must not pass through the internet.

Then I'd have to say frames are about it.
Frames are evil, though, and require a lot of coding of workarounds to
deal with issues they cause if they're used on an internet site.

--
--
~kaeli~
Going to church doesn't make you a Christian any more than
standing in a garage makes you a car.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[neerolyte]

> Then I'd have to say frames are about it.

Frames are evil, though, and require a lot of coding of workarounds to
deal with issues they cause if they're used on an internet site.

hmmm, I don't want to use frames, I've worked out how to achieve the same
thing by using a random variable and retrieving as much client specific info
from the browser as I can, as well as their IP address, this works well, but
being able to store the pass as I wanted to would have given me as close as
you can get with non ssl sites to a secure login

[kaeli]

In article <bt***********@ otis.netspace.n et.au>,
ne*******@netsp ace.nOsPaM.net. au enlightened us with...

Then I'd have to say frames are about it.
Frames are evil, though, and require a lot of coding of workarounds to
deal with issues they cause if they're used on an internet site.

hmmm, I don't want to use frames, I've worked out how to achieve the same
thing by using a random variable and retrieving as much client specific info
from the browser as I can, as well as their IP address, this works well, but
being able to store the pass as I wanted to would have given me as close as
you can get with non ssl sites to a secure login

Encrypt the data.
To log in, the user name and password have to go to the server.
Otherwise, how does the server know it's valid? So, I assume you don't
want to send it as plain text, not that you don't want to send it at
all.

I don't know how good this is, but I found this with Google.
http://pajhome.org.uk/crypt/md5/chaplogin.html

It uses a javascript hash function to send the password.

--
--
~kaeli~
If a parsley farmer is sued, can they garnish his wages?
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace