Forum Moderators: open

Message Too Old, No Replies

Cookie not defined

how to prevent errors

         

fashezee

7:46 pm on Aug 10, 2002 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I have my site setup so that when a user logs in, a cookie is sent to them. When the user clicks on the log out button,
they're sent to the home page. I have the home page coded so that if there is a cookie defined it will erase it.

Here's the problem. When a user logs out, the cookie is removed, but if the user were to use there back button on their
browser, they would fall on a page that is looking for a cookie but not finding one, hence displaying the error message.

How can I solve this?

rewboss

9:36 pm on Aug 10, 2002 (gmt 0)

10+ Year Member



On each page that uses cookies, check that a cookie is actually defined before trying to use it.

joshie76

11:02 am on Aug 11, 2002 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



You should always have error handling for such exceptions in place.

Every page that requires a cookie should first check for one, if it's not -present then redirect to a login page (or error page, or whatever's appropriate). In some cases it may be necessary to first validate the cookie too.

The golden rule is not to assume the data the client is sending can be incorrect (even though you can't recreate it in your testbed). Check and verify as much as you can and handle the exceptions appropriately.

Most people now rely on client-side JavaScript to validate data entry (is it a date/number/e-mail address etc), but almost everything else you should check.

rewboss

2:23 pm on Aug 11, 2002 (gmt 0)

10+ Year Member



The golden rule is not to assume the data the client is sending can be incorrect

I think you mean: "The golden rule is not to assume the data the client is sending cannot be incorrect", which is a triple negative. Hmm. Maybe: "The golden rule is never to assume the data is always correct"? :)

Most people now rely on client-side JavaScript to validate data entry (is it a date/number/e-mail address etc), but almost everything else you should check.

I'd go further than that, and say that even if you do put client-side form validation in, you shouldn't rely on it, for the simple reason that if JavaScript is disabled or unavailable, the form will be sent unvalidated. Use it as an extra user-friendly feature to avoid the waits and server load incurred in submitting and processing invalid forms, but don't assume it will always work. I would rewrite the above quote:

"Most people now rely on client-side JavaScript to validate data entry, but you should still check absolutely everything server-side, too."

joshie76

8:23 am on Aug 12, 2002 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I edited that sentence about six times and obviously didn't re-read the whole thing... oops.

Rewboss is right, you should check everything. In my experience though this is rarely the case (though my experience is nearly all intranet applications where JavaScript is a cert). If you're on the www with open access - definitely check everything.