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]

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]

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.

--

 

[Guido Wesdorp]

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="JavaScript">
document.write(window.myVar);
window.myVar = "this is stored?";
document.write(window.myVar);
</script>

the output is ALLWAYS "undefinedthis is stored?"

 

[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,

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

 

[kaeli]

they are stored in the browser!
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]

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.

--

 

[neerolyte]

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.

not true, there a freely available algorithms for md5 in java script, so i
just use that for the password, if i instead doing it by taking md5(pass +
randomVariable) at both the server and client end for each page load, i have
way of being sure that the client has the correct password, and also that no
one else is using the session by simply setting a cookie in there browser to
the output from md5(pass) or the initial md5(pass + randomVariable)

what i wanted to do was store the pass in a way that it would not be sent to
the server, but this seems to hard.

 

[Thomas 'PointedEars' Lahn]

Please shorten your attribution.

Cookies are always sent to the server.

This is utter nonsense. Cookies are *never* sent to the
server. Instead, the server can send information via HTTP
to the user agent in order to write/retrieve cookie
*information* stored locally, in small files (cookies.txt
in Netscape). That information can be only retrieved by
server-side applications if allowed by the user and is
in compliance with certain built-in security precautions.

For common JavaScript cookies and cookie information with
document.cookie, they *never* leave the client, as the
JavaScript code that sets and retrieves them runs
client-side, though it must be downloaded from the server
first.


PointedEars

 

[Steve van Dongen]

Please shorten your attribution.

If that comment is intended for me, perhaps you could not use words I
don't know.

This is utter nonsense. Cookies are *never* sent to the
server. Instead, the server can send information via HTTP
to the user agent in order to write/retrieve cookie
*information* stored locally, in small files (cookies.txt
in Netscape). That information can be only retrieved by
server-side applications if allowed by the user and is
in compliance with certain built-in security precautions.

And how do you think server-side applications get the cookie? The
client always sends it.

For common JavaScript cookies and cookie information with
document.cookie, they *never* leave the client, as the
JavaScript code that sets and retrieves them runs
client-side, though it must be downloaded from the server
first.

RFC 2109 HTTP State Management Mechanism
http://www.w3.org/Protocols/rfc2109/rfc2109

4.3.4 Sending Cookies to the Origin Server

When it sends a request to an origin server, the user agent sends a
Cookie request header to the origin server if it has cookies that
are applicable to the request, based on
* the request-host;
* the request-URI;
* the cookie's age.

Regards,
Steve

 

[Thomas 'PointedEars' Lahn]

If that comment is intended for me, perhaps you could not use words I
don't know.

Gladly.

The attribution is the (introducing) part of a followup that identifies
who wrote the quoted text, for making discussions with several quoting
levels easily followable. It is good practice (and thus recommended by
Netiquette) to keep it short, so that it does not exceed one line
(which is therefore called "attribution line".)

[...] Cookies are *never* sent to the server. Instead, the server
can send information via HTTP to the user agent in order to
write/retrieve cookie *information* stored locally, in small files
(cookies.txt in Netscape). That information can be only retrieved
by server-side applications if allowed by the user and is in
compliance with certain built-in security precautions.

And how do you think server-side applications get the cookie?

See below.

The client always sends it.

Its data, not the cookie itself which remains on the client.

RFC 2109 HTTP State Management Mechanism
http://www.w3.org/Protocols/rfc2109/rfc2109

4.3.4 Sending Cookies to the Origin Server [...]

Ah, my bad. I thought that an additional request from the
server-side application to the user agent was necessary to
retrieve cookies. Thanks for clarification.


PointedEars

 

[Lasse Reichstein Nielsen]

The attribution is the (introducing) part of a followup that identifies
who wrote the quoted text, for making discussions with several quoting
levels easily followable. It is good practice (and thus recommended by
Netiquette) to keep it short, so that it does not exceed one line
(which is therefore called "attribution line".)

It should be mentioned that there is contention about this. The
attribution is only called "attribution line" by some, and other just
want to keep it as short as necessary. Your attribution was fine by
me, and would almost have fit on one line if the name was shorter
(e.g., not including the extra 'PointedEars').

Its data, not the cookie itself which remains on the client.

A cookie is data. I fail to see the distinction. A cookie is an
amount of data which has been stored on the web client. It is marked
with a scope for which it applies (server, path, and expiration date).
Whenever the client contacts a server for which this scope matches
using the HTTP protocol, the cookie data is sent to the server along
with the request. If anything, it is the data, not the cookie (which
includes the scope) which is sent to the server.

/L

 

[Steve van Dongen]

If that comment is intended for me, perhaps you could not use words I
don't know.

Gladly.

The attribution is the (introducing) part of a followup that identifies
who wrote the quoted text, for making discussions with several quoting
levels easily followable. It is good practice (and thus recommended by
Netiquette) to keep it short, so that it does not exceed one line
(which is therefore called "attribution line".)

Alright. I was just using Agent's default. The date and time's
largely irrelevant anyways so it's gone.

Cheers,
Steve

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in
Thomas 'PointedEars' Lahn

If that comment is intended for me, perhaps you could not use words I
don't know.

Gladly.

The attribution is the (introducing) part of a followup that identifies
who wrote the quoted text, for making discussions with several quoting
levels easily followable. It is good practice (and thus recommended by
Netiquette) to keep it short, so that it does not exceed one line
(which is therefore called "attribution line".)

Ignore the Prussian.

An attribution can consider whatever its constructor considers
reasonable.

ID, newsgroup, attributee, and origin all have their uses under
different circumstances; what is sufficient to an on-line reader with
immediate Google access, for example, is not necessarily sufficient for
one using an off-line reader on an isolated computer.

The Prussian should, however, shorten his headers. They contain a
redundant In-Reply-To line, which merely repeats the final entry in the
References line.

The Prussian's inappropriate "bandwidth-saving" demands cost more
bandwidth in refutation than they are ever likely to save.

 

[Alex Fitzpatrick]

For common JavaScript cookies and cookie information with
document.cookie, they *never* leave the client, as the
JavaScript code that sets and retrieves them runs
client-side, though it must be downloaded from the server
first.

Hmm, I seem to recall building a cookie on the client and then
submitting a form, and being able to retrieve the users cookie on the
server.

But this was about two years ago, memory does fade over time...