How to force a Warning Page on my site

[JSchwarz]

When user's come to my site, most will probably start at the opening page: a legal warning which they must read to enter. Of course, even moderate power-users can save a URL and start somewhere in the middle of the site, skipping the legal warning; and giving our lawyers agita.

How can I force the warning page to appear when a user's previous URL does not match the URL of my site or otherwise force the warning when user's first enter the site?

Thanks in advance,
Jeff

[David Harrison]

If after the warning page you were to link to a page called first.html, in the link put this:
first.html?warning=read

and then have a simple script that detects this, and if it finds warning="read" then allow them to browse that page, if not, redirect them to your homepage. I don't know whether the ?warning=read will also be saved with the address of the page, so you'll have to try it out first.

[jeffmott]

I don't know whether the ?warning=read will also be saved with the address of the pageIt will. It is still a part of the URI.

I would suggest using cookies. Your warning page will set a cookie, indicating that computer has been to that page. Then all other pages check for the existence of that cookie. If it does not exist, they are redirected.

Setting a cookie can be done client-side or server-side. Server-side would be the more reliable method.

Setting a cookie:
* JavaScript (http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/document.html#1193577) (client-side)
* Perl (http://www.perldoc.com/perl5.8.0/lib/CGI.html#HTTP-COOKIES) (server-side)
* PHP (http://us4.php.net/manual/en/function.setcookie.php) (server-side)

[David Harrison]

However jeffmot, he would have to make sure that he deletes the cookies when the user leaves the site, otherwise they could jump straight to a page further on in the site a week later, not having read the warning.

[jeffmott]

I suppose I'll have to go and re-read everything I havn't read in the past week then. Since you say a passing of that amount of time negates the fact that it was read. :p

In the case of public computers, though, you are very much correct. Leaving the cookie would allow new users on a public computer to skip the warning page, but force returning users with their own personal computers to go through it every time and make bookmarking a specific page within the site completely useless. The obvious alternative: allowing the cookie to remain on the computer makes the site more friendly to recurring visitors with their own PC, but may allow new users to skip the message if the computer they are using happened to agree to message some time in the past.

So this choice is left to the original poster. The links I posted earlier should provide more than enough information for setting expiration dates.

[JSchwarz]

Thanks for the help, and the discussion of each's merits.

I went with client-side cookies because I didn't want the indicator to be part of the URL, where anyone slightly better than a moderate power-users could grab it and append it to their bookmark. I'll change it to server-side cookies, which are probably more appropriate and faster response time, as soon as I learn how to do that on the server I'm using (Lotus Domino).

Further, if I understand what I'm reading (in O'Reilly JavaScript books) correctly, then if no expiration date is set, cookies expire the moment you close your browser. My testing confirms this.

Public PCs are not an issue. This is highly sensitive government information and I'm sure that when my app is complete we will not be allowing users to use it from public sites (how to do that may even be my next post!).

I worked around the bookmark issue by storing the user's original target and then, after they receive (and have *obviously* have read the warning without just clicking 'OK') the warning page, send them back to it.

The way I see it, my only remaing issue (besides keeping public PCs from using this site), is users who might open their browser, go to my site, then leave their browser open overnight and then come back (assuming Windows doesn't crash them). I think I can live with that. I may consider setting a short, say 2 hour, expiration period, but the documentation doesn't say whether that would override keeping the cookie while the browser was open (in other words, if I see the warning page, set the cookie, and browse continuously for over 2 hours, would I be forced to the warning page again?).

Thanks again. Following is my code (if you're at all curious).

I call this function in the onLoad of every single form. It checks the cookie to see if the user has been warned. If no, then it stores the target URL and sends the browser to the application root (the Warning page):

function forceWarning() {
// Check so see if the user has received their legal warning. If not, redirects them to it.
var beenWarned = getCookie("ASSIST");
var target = document.URL;
var path = target.substring(0, target.search(".nsf")+4)

if (!beenWarned) {
var URL = path + "/?OpenDatabase";
URL += "&target=" + target;
location.replace(URL);
return false;
} else return true; //if user hasn't been warned (beenWarned != path)
} // function forceWarning()


The following code is in the Warning page's onLoad:

var target = document.URL;
// I'm trying to figure out how to use the cookie path here, not working yet.
var path = target.substring(0, target.search(".nsf")+4)

setCookie("ASSIST", true);

This code is in the OK button on the Warning page. It sends the user to the target, if valued, or the top of the database. thisForm is defined in the initialize() routine of every form (thisForm = document.forms[0]; see http://forums.webdeveloper.com/showthread.php?s=&threadid=10868). target is a field on the Warning page which pulls the value after "target=" from the QUERY_STRING of the URI. And DB is a field with the location of the application ("ASSIST/ASSIST.nsf"):location.href = (thisForm['target'].value) ? thisForm['target'].value :
"/" + thisForm['DB'].value + "/vwSSStructure?OpenView";