Re: [cobalt-users] RaQ4 - shared SSL and .cgi/.pl

[Rocky Hetherington <mailinglists@xxxxxxxxxx>]

At 00:19 18/10/2000, you wrote:
> Has anybody solved the shared SSL alias thing on the RaQ4 ...?
> I've been offline a few days moving my offices (you should have
> seen my mailbox this morning - agh!).

Judging by the amount of list emails i get per day i'm surprised you didn't 
run out of disc space. ^_^

> Last I saw in the digest, it worked for running a file (page.html) via
> SSL, but not a script like formmail.cgi/.pl
>
> This is based on the AliasMatch mod suggested by Rocky Hetherington,
> which a few of us have tried.
>
> Anybody have it working?

Yep i've now got mine working fine.

A modified version of cgi wrap had to be installed.  Duncan Laurie posted 
details of this, which i have included below.

I have also setup a few more aliasmatches to make things easier for my 
customers.  Normal html/PHP pages can be called in the standard way 
(https://www.order-securely.co.uk/sites/www.domain.com) while cgi scripts 
can be called from https://www.order-securely.co.uk/cgi-bin/www.domain.com 
which points to a cgi-bin/www.domain.com directory inside the virtual sites 
web directory.

I've also setup one for a modified agoracgi shopping cart system which can 
be called from https://www.order-securly.co.uk/alstore/www.domain.com and 
which points to an alstore/www.domain.com directory.

All work fine now.

What i am looking for is a way of setting up the auto generation of the 
www.domain.com directory when the site is setup.  I've added the cgi-bin 
one to /etc/skel/group/en_US/web but i can't seem to get the www.domain.com 
one to generate correctly

> oh yeah... does anyone know how to setup local over-rides for the
> 404 error page; e.g., custom error pages on a siteN by siteN basis?

Create a .htaccess file in the directory you want the error pages to apply 
to (and all subdirectories too) and put

ErrorDocument 404 http://www.domain.com/404.html
ErrorDocument 500 http://www.domain.com/500.html

and so on for all the error pages you wish to create.

HTH.

Here's the email that Duncan Laurie posted with the location of the 
modified cgi wrap.

[Begin Email]
The problem with running CGIs through an AliasMatch is that cgiwrap relies
heavily on the PATH_INFO and PATH_TRANSLATED variables to determine
what script to run and to perform security checks.. Much of this is because
cgiwrap is a 3rd party app, not an apache module--it must take the
environment that apache gives for granted. So an AliasMatch like:

AliasMatch ^/secure/([^/]+)(/(.*))? /home/sites/$1/web/$3

passes cgiwrap PATH_INFO and PATH_TRANSLATED variables that do not match up:

PATH_TRANSLATED=/home/sites/www.domain.com/web/script.cgi
PATH_INFO=/secure/www.domain.com/script.cgi

Fixing this part is a pretty trivial change to the AliasMatch:

AliasMatch ^/secure/([^/]+)(/(.*))? /home/sites/$1/web/secure/$1/$3

but it means secure CGIs must be in the directory specified by PATH_INFO,
in relation to the web root of the site. After this CGIs will work, but
only if you refer to the site by its groupname, not the fqdn. This is
because it does security checks against the groupname given by the
PATH_TRANSLATED variable (the $1 regex from the AliasMatch) and fails
because the group "www.domain.com" does not exist.

To fix this I modified cgiwrap to obtain the group info from the file
referred to by PATH_TRANSLATED; which it then compares to the owner of the
file to verify the user is a member of that group (a site administrator).
This may not be the ideal solution, but it is minor and doesn't require
making massive changes to cgiwrap. Now with the above AliasMatch and
this cgiwrap change you can access CGIs like so:

https://www.secure-server.com/secure/www.domain.com/formmail.pl

If the script is in:

/home/sites/www.domain.com/web/secure/www.domain.com/formmail.pl

You can find the new cgiwrap RPM (and SRPM) at:
ftp://ftp.cobaltnet.com/pub/users/duncan/cgiwrap/cgiwrap-3.6.4-C11.i386.rpm

[End Email]

--
Rocky Hetherington | mailinglists@xxxxxxxxxx
Alaula Limited
WebDesign | http://www.alaula.com
Hosting and Domain registration | http://www.alaula.net