"Fossies" - the Fresh Open Source Software Archive

Member "cgiwrap-4.1/htdocs/tricks.html" (16 Jun 2008, 10578 Bytes) of package /linux/www/old/cgiwrap-4.1.tar.gz:

As a special service "Fossies" has tried to format the requested source page into HTML format using (guessed) HTML source code syntax highlighting (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 <TITLE>CGIWrap - Tips and Tricks</TITLE>
    2 <CENTER><H2>CGIWrap - Tips and Tricks</H2></CENTER>
    3 <HR><P>
    6 <PRE>
    7 Ok, here's a few examples on how you can use mod_rewrite to rewrite your 
    8 CGIwrap URL's in a way that is totally transparent to the end user.
   10 Example #1 - Basic Rewriting of CGIwrap URL's
   12 In this example all VirtualHosts are in the format username.domain.com
   13 All user's CGI directory's are ~/cgi/
   15 In httpd.conf :-
   17 # I control the Scope of these Rewrite with a VirtualHost Directive
   18 # I dont want these rewrites to apply to the Main VHost, only to the customers
   19 # VHosts (which are also rewritten)
   20 &lt;VirtualHost;
   22 # set up scriptaliases for the man cgi-bin
   23 ScriptAlias /cgi-bin/ /path/to/main/cgi-bin/
   25 # Init out rewrite engine
   26 RewriteEngine On
   28 RewriteMap lowercase int:tolower
   30 # keep the main CGI bin intact
   31 RewriteCond %{REQUEST_URI} !^/cgi-bin/
   32 # make the requested vhost lowercase in case some doofus uses wierd caps
   33 RewriteCond ${lowercase:%{HTTP_HOST}} ^[a-z-][-0-9]+\.domain\.com$
   35 RewriteRule ^(.+) ${lowercase:%{HTTP_HOST}}$1 [C]
   37 # do the magic
   38 RewriteRule ^([a-z-][-0-9]+)\.domain\.com/cgi/(.*) /cgi-bin/cgiwrap/$1/$2 [PT]
   39 RewriteRule ^([a-z-][-0-9]+)\.domain\.com/cgi-d/(.*) /cgi-bin/cgiwrapd/$1/$2 [PT] 
   40 RewriteRule ^([a-z-][-0-9]+)\.domain\.com/nph-cgi/(.*) /cgi-bin/nph-cgiwrap/$1/$2 [PT]
   41 RewriteRule ^([a-z-][-0-9]+)\.domain\.com/nph-cgi-d/(.*) /cgi-bin/nph-cgiwrapd/$1/$2 [PT]
   43 &lt;VirtualHost>
   45 Example #2 - Rewriting with a RewriteMap
   47 RewriteMap's are alot faster than standard regexp based rewrite because
   48 mod_rewrite caches each map lookup, until the mtime of the mapfile changes,
   49 thus removing the needs for interpratation of the Rules each time they are
   50 requested
   52 This is a complete example, as used on our production webserver
   53 (http://www.server101.com/)
   55 # Again use a VirtualHost directive to control the scope
   56 &lt;VirtualHost;
   57 ScriptAlias /cgi-bin/ /s101/current/cgi-bin/
   59 RewriteEngine On
   60 RewriteMap lowercase int:tolower
   61 # map file which contains key/value information for all our customer
   62 # subdomains (username.server101.com) and any domains they host with us
   63 # map file is of format
   64 # username.server101.com /s101/home/user
   65 # domain.com /s101/home/user
   66 # www.domain.com /s101/home/user
   67 RewriteMap vhost dbm:/etc/apache/hostmap
   68 # map file which contains key/value information for path info for customers
   69 # cgi 
   70 # format:
   71 # username.server101.com /cgi-bin/cgiwrap/
   72 # ...
   73 RewriteMap cgi   dbm:/etc/apache/cgimap
   75 # keep our CGI bin intact
   76 RewriteCond %{REQUEST_URI} !^/cgi-bin/
   77 # Other Aliases we have that we want to stay intact
   78 RweriteCond %{REQUEST_URI} !^/icons/
   79 RewriteCond %{REQUEST_URI} !^/cgi/
   80 RewriteCond %{REQUEST_URI} !^/stats/images/
   81 # we dont want the machine's name to be rewritten or even attempt to be
   82 # rewritten as a failed map lookup will cause a pass through of the main vhost
   83 RewriteCond ${lowercase:%{HTTP_HOST}} !^launch.server101.com$ [NC]
   84 # heres where the magic starts
   85 RewriteCond ${lowercase:%{HTTP_HOST}} ^(.+)$
   86 RewriteCond ${vhost:%1} ^(/.*)$
   87 RewriteRule ^/(.*) %1/$1
   89 # Ok with the handling of the user vhosts/domains out of the way we can get on
   90 # to the CGI stuff
   92 # all our users personal cgi's are ~/cgi/
   93 RewriteCond %{REQUEST_URI}  ^/cgi/
   94 # keep the global cgi-bin intact still
   95 RewriteCond %{REQUEST_URI} !^/cgi-bin/
   96 # and our other aliases
   97 RewriteCond %{REQUEST_URI} !^/icons/
   98 RewriteCond %{REQUEST_URI} !^/stats/images/
   99 # here we go again...
  100 RewriteCond ${lowercase:%{HTTP_HOST}} ^(.+)$
  101 RewriteCond ${cgi:%1} ^(/.*)$
  102 RewriteCond ^/cgi/(.*)$ %1/$1 [PT]
  104 &lt;VirtualHost&gt;
  106 and thats it. We dont allow access to any of the *cgiwrapd's as they give out a
  107 little more info than we want our users to have access to...
  109 comments/corrections roady@linux-solutions.org
  111 --
  112 Ben O'Shea
  114 </PRE>
  115 <HR>
  117 <PRE>
  118 From: Shane DeRidder <shane@together.net>
  120 Actually, if you use Apache 1.1 (recently released), you can use their
  121 built-in handlers like:
  123 AddHandler cgi-wrapper .cgi
  124 Action cgi-wrapper /virtual-path-to-wrapper/username
  126 Of course, this requires all cgi's to end in '.cgi' but there is no need
  127 to force the cgis to remain in one directory (as long as you compile the
  128 wrapper to believe cgi's are in the user's root html directory).
  130 I have my server configured to disallow all CGIs, so users are forced to
  131 use the wrapper...works better than I had ever expected.  They can do
  132 anything with their web sites - and none of them realize the wrapper
  133 is in use.
  135 Shane-
  137 --
  138 Shane DeRidder     | System Administrator / Webmaster
  139 shane@together.net | Together Networks
  140 (802)860-5166      | http://www.together.net
  142 </PRE>
  144 <HR>
  146 <PRE>
  147 For netscape server in obj.conf:
  149 NameTrans fn="pfx2dir" from="/cgi" dir="path_to_cgiwrap" name="cgi"
  150 NameTrans fn="pfx2dir" from="/cgid" dir="path_to_cgiwrapd" name="cgi"
  152 -----
  153 Joe Hourcle <oneiros@www.gwu.edu>
  154 Web Development Staff
  155 Computer and Information Resource Center
  156 The George Washington University
  158 </PRE>
  160 <HR>
  162 <PRE>
  163 From: Seth Chaiklin <seth@psy.au.dk>
  165 cgiwrapd and nph-cgiwrapd provide information about the installation of
  166 your web-server that you might not want to make generally available.
  168 Using the <Location> directive under Apache 1.1 (or greater) it
  169 is possible to restrict who is allowed to use these two debugging
  170 versions of cgiwrap.
  172 For example:
  173 &lt;Location /cgi-bin/cgiwrapd&gt;
  174 Order deny,allow
  175 Deny from all
  176 Allow from &lt;your ip number here&gt;
  177 &lt;/Location&gt;
  179 &lt;Location /cgi-bin/nph-cgiwrapd&gt;
  180 Order deny,allow
  181 Deny from all
  182 Allow from &gt;your ip number here&gt;
  183 &lt;/Location&gt;    
  185 Depending on what value you place for allow from, you can control how
  186 widely these debugging versions
  187 are available.
  188 </PRE>
  190 <HR>
  192 <PRE>
  194 Date: Sun, 7 Dec 1997 23:20:28 -0500 (EST)
  195 From: Yuji Shinozaki <yuji@cs.duke.edu>
  197 Look at the Rewrite rules.  You will need to activate mod_rewrite
  198 and recompile (see the Apache documentation and Configuration file:
  199 you will need to uncomment the follwing line and recompile.
  201 Module rewrite_module      mod_rewrite.o
  203 )
  205 For an example of the runtime configuration, in the srm.conf you could
  206 have: 
  208 RewriteEngine on
  209 RewriteRule  ^/~([^/]+)/cgi-bin/(.*)    /cgi-bin/cgiwrap/$1/$2 [PT] 
  210 RewriteRule  ^/~([^/]+)/cgi-bin-d/(.*)  /cgi-bin/cgiwrapd/$1/$2 [PT] 
  211 RewriteRule  ^/~([^/]+)/nph-bin-d/(.*)  /cgi-bin/nph-cgiwrapd/$1/$2 [PT] 
  212 RewriteRule  ^/~([^/]+)/nph-bin/(.*)    /cgi-bin/nph-cgiwrap/$1/$2 [PT] 
  214 Which translates http://server.addr/~user/cgi-bin/program to
  215 http://server.addr/cgi-bin/cgiwrap/user/program. Also (in this example) 
  216 http:/server.addr/~user/cgi-bin-d/program is translated to
  217 http://server.addr/cgi-bin/cgiwrapd/user/program, to provide debugging
  218 support.  And so on... 
  220 The setup of cgi-wrap will determine where the scripts actually reside.
  221 (and I would actually put the script in a directory NOT in the
  222 usual public_html tree, because then it is possible for an anonymous user
  223 to read the cgi scripts).
  225 I have not implemented this to support virtual domains separately, but
  226 it should be possible.
  228 Hope this is helpful.
  230 yuji
  231 </PRE>
  233 <P>
  235 <PRE>
  236 An alternative Action based execution tip Mr Yowler:
  238 Just a one-time contribution to your "Tips and Tricks" notes...
  240 The tip descibed by Shane DeRidder works nicely, except that he left out one important detail:  whatever path you set up, as the "Action" for "cgi-wrapper", must be defined in a "ScriptAlias" directive, so that Apache knows to run the cgiwrap executable, 
  241 rather than treat it as static content.  Here is a sample from my own setup; a VirtualHost on a webserver that lives in a chrooted environment:
  243 <VirtualHost *>
  244   ServerAdmin admin@somedomain.com
  245   DocumentRoot /
  246   ServerName www.somedomain.com
  247   ErrorLog /path/to/logs/www.somedomain.com-error_log
  248   CustomLog /path/to/logs/www.somedomain.com-access_log
  249   ScriptAlias /cgi-bin/ /serverwide/script/path/
  250   <IfModule mod_userdir.c>
  251     UserDir public_html
  252   </IfModule>
  253   <Directory /home/*/public_html>
  254    AllowOverride AuthConfig Limit
  255    Options Indexes Includes ExecCGI
  256    Action cgi-wrapper .cgi
  257   </Directory>
  258 </VirtualHost>
  260 This configuration allows users within the www.somedomain.com site, run .cgi scripts, from wherever they want, within their home directories.  It's is relatively transparent, as Shane DeRidder said, execpt for two things:
  262 1) Any call for a script, that results in an error within CGIwrap (such as a call for a script that does not exist), results in an error, from the CGIwrap executable.  That error clearly labels itself as coming from CGIwrap, identifying to the user, that 
  263 CGIwrappers are in place.
  265 2) Any attempt to password-protect access to the scripts, using the .htaccess mechanism, will fail, since the CGIwrapper is outside of the users' writable file system tree.  Ordinarily, the user's would simply .htaccess-control the directory containing th
  266 e script that they wrote.  With CGIwrap controlling script execution, however, Apache does not get an opportunity to check the .htaccess rules, for the script (it can only check rules for the CGIwrap executable, itself, and there aren't any, since it is o
  267 utside of the area that the users can modify), and therefore, any script that the user intended to be password-protected or otherwise access-restricted, isn't.
  269 I suspect that a careful application of suEXEC would resolve the latter issue, though the cost of doing so, would be the loss of some of the cooler resource-limiting functions of CGIwrap.  As for the former issue, well...  It would be possible to change t
  270 he CGIwrap source code, to display errors in whatever format suits the webserver administrator, but is seems as though it would be a lot more effort than it's worth.  In my environment, I merely want to keep CGIwrappers transparent to the users, to avoid 
  271 breaking scripts that would otherwise work - I'm not actually trying to keep the wrappers a secret...  :)  In fact, I would actually like them to take advantage of the debugging information that cgiwrapd offers them...  :)
  273 The symptom of failing to use ScriptAlias, on my system, was reflected in the Apache www.somedomain.com-error_log, as a "File does not exist: /serverwide/script/path/~someuser/scriptname.cgi".
  275 Anyhow, that's my little contribution.  I am not on the mailing list (that's what I need - MORE email...  <grin>), and I just had the one thing about the ScriptAlias requirement, to add to the "Tips and Tricks" - otherwise I would have simply posted it to
  276  the mailing list.  I spent nearly a full day, tracking that one down... Don't I feel the idiot, now...  :)
  278 </PRE>