[plug] Apache Server Client User Aggreement

[Shayne O'Neill]

another possible way is to write a redirect script that looks for a
referer link.

if the referer is anything but the site, redirect to the accept page,
presumably the url is available. then the accept link links back to the
required page.

this also should break file leaching too, which is kinda nifty.

you'll have to look up anti-leach scripts and use some headscratching, but
I reckon it'll work.

--
"Well, I think if you say you're going to do something and don't do
it, that's trustworthiness."
-- George Bush on CNN online chat, Aug.30, 2000
RIAA Copyright notice trap: http://guild.murdoch.edu.au/~shayne/

On Sun, 7 Nov 2004, James Devenish wrote:

> In message <418E0693.1060003 at tigris.org>
> on Sun, Nov 07, 2004 at 07:27:15PM +0800, Timothy White wrote:
> > I would like to set up my Apache server so that it displays a
> > 'conditions of use' message that the user most accept before using the
> > server. Like /etc/issue and /etc/issue.net (for ssh)
> > Is this possible and easy or should I write a PHP script of some sort?
> > (e.g. Have it password protected and the PHP script hands out the
> > password to those who agree to the conditions)
>
> What you are proposing is quite astounding as a "server-wide"
> proposition, but is certainly achievable if you are prepared to learn
> what is going on and how it will interact with your own web
> applications. This sort of things can generally be achieved pretty
> easily if it is already given that all web pages are part of a large
> "web application": you would build the terms and conditions into the
> application itself. Otherwise, you will need to go to a bit of effort.
> Perhaps the easiest way, then, is to make use of HTTP features. One way
> would be:
>
>  - Set up your server/virtual host so that it requires authentication.
>  - Users will attempt to view a webpage, which I will refer to as the
>    "resource". when such attempts are made for the first time, they will
>    be prompted for a username or password. if they click 'cancel', they
>    will see an HTTP 401 error page.
>  - Redefine Apache's 401 errordocument (401 is the HTTP code for
>    "unauthorised") so that it displays the terms and conditions and has
>    an 'accept' button. It should also have a hidden field that contains
>    the URL of the resource.
>  - The 'accept' button should submit to a page (PHP script) which
>    displays the username&password and contains a link to the resource.
>    This page must *not* be password-protected, but may rely on hidden
>    form-fields in the 401 errordocument.
>  - Once the user has read the page, the user clicks on the link to the
>    resource and is prompted for the username/password, which he or she
>    can now enter.
>
> This procedure might not be ideal (e.g. the users initially see the
> username/password box instead of the terms and conditions), but it is a
> "quick" solution that will work with either Apache 1 or Apache 2 and is
> likely to be compatible with a wide range of existing content on your
> website. I can imagine that an alternative, which might be more polished
> but would also require more learning and development, is to insert some
> kind of "filter" into your Apache request handling stage, and have it
> check for cookie-based authorisation that you have defined. This might
> depend on which version of Apache you are using.
>
>
> _______________________________________________
> PLUG discussion list: plug at plug.linux.org.au
> http://mail.plug.linux.org.au/cgi-bin/mailman/listinfo/plug
> Committee e-mail: committee at plug.linux.org.au
>