"Fossies" - the Fresh Open Source Software Archive

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


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

    1                           CGIWrap - Tips and Tricks
    2      __________________________________________________________________
    3 
    4 Ok, here's a few examples on how you can use mod_rewrite to rewrite your
    5 CGIwrap URL's in a way that is totally transparent to the end user.
    6 
    7 Example #1 - Basic Rewriting of CGIwrap URL's
    8 
    9 In this example all VirtualHosts are in the format username.domain.com
   10 All user's CGI directory's are ~/cgi/
   11 
   12 In httpd.conf :-
   13 
   14 # I control the Scope of these Rewrite with a VirtualHost Directive
   15 # I dont want these rewrites to apply to the Main VHost, only to the customers
   16 # VHosts (which are also rewritten)
   17 <VirtualHost 192.168.0.1:80>
   18 
   19 # set up scriptaliases for the man cgi-bin
   20 ScriptAlias /cgi-bin/ /path/to/main/cgi-bin/
   21 
   22 # Init out rewrite engine
   23 RewriteEngine On
   24 
   25 RewriteMap lowercase int:tolower
   26 
   27 # keep the main CGI bin intact
   28 RewriteCond %{REQUEST_URI} !^/cgi-bin/
   29 # make the requested vhost lowercase in case some doofus uses wierd caps
   30 RewriteCond ${lowercase:%{HTTP_HOST}} ^[a-z-][-0-9]+\.domain\.com$
   31 
   32 RewriteRule ^(.+) ${lowercase:%{HTTP_HOST}}$1 [C]
   33 
   34 # do the magic
   35 RewriteRule ^([a-z-][-0-9]+)\.domain\.com/cgi/(.*) /cgi-bin/cgiwrap/$1/$2 [PT]
   36 RewriteRule ^([a-z-][-0-9]+)\.domain\.com/cgi-d/(.*) /cgi-bin/cgiwrapd/$1/$2 [P
   37 T]
   38 RewriteRule ^([a-z-][-0-9]+)\.domain\.com/nph-cgi/(.*) /cgi-bin/nph-cgiwrap/$1/
   39 $2 [PT]
   40 RewriteRule ^([a-z-][-0-9]+)\.domain\.com/nph-cgi-d/(.*) /cgi-bin/nph-cgiwrapd/
   41 $1/$2 [PT]
   42 
   43 <VirtualHost>
   44 
   45 Example #2 - Rewriting with a RewriteMap
   46 
   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
   51 
   52 This is a complete example, as used on our production webserver
   53 (http://www.server101.com/)
   54 
   55 # Again use a VirtualHost directive to control the scope
   56 <VirtualHost 165.90.18.194:80>
   57 ScriptAlias /cgi-bin/ /s101/current/cgi-bin/
   58 
   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
   74 
   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
   88 
   89 # Ok with the handling of the user vhosts/domains out of the way we can get on
   90 # to the CGI stuff
   91 
   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]
  103 
  104 <VirtualHost>
  105 
  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...
  108 
  109 comments/corrections roady@linux-solutions.org
  110 
  111 --
  112 Ben O'Shea
  113 
  114      __________________________________________________________________
  115 
  116 From: Shane DeRidder
  117 
  118 Actually, if you use Apache 1.1 (recently released), you can use their
  119 built-in handlers like:
  120 
  121 AddHandler cgi-wrapper .cgi
  122 Action cgi-wrapper /virtual-path-to-wrapper/username
  123 
  124 Of course, this requires all cgi's to end in '.cgi' but there is no need
  125 to force the cgis to remain in one directory (as long as you compile the
  126 wrapper to believe cgi's are in the user's root html directory).
  127 
  128 I have my server configured to disallow all CGIs, so users are forced to
  129 use the wrapper...works better than I had ever expected.  They can do
  130 anything with their web sites - and none of them realize the wrapper
  131 is in use.
  132 
  133 Shane-
  134 
  135 --
  136 Shane DeRidder     | System Administrator / Webmaster
  137 shane@together.net | Together Networks
  138 (802)860-5166      | http://www.together.net
  139 
  140      __________________________________________________________________
  141 
  142 For netscape server in obj.conf:
  143 
  144 NameTrans fn="pfx2dir" from="/cgi" dir="path_to_cgiwrap" name="cgi"
  145 NameTrans fn="pfx2dir" from="/cgid" dir="path_to_cgiwrapd" name="cgi"
  146 
  147 -----
  148 Joe Hourcle
  149 Web Development Staff
  150 Computer and Information Resource Center
  151 The George Washington University
  152 
  153      __________________________________________________________________
  154 
  155 From: Seth Chaiklin
  156 
  157 cgiwrapd and nph-cgiwrapd provide information about the installation of
  158 your web-server that you might not want to make generally available.
  159 
  160 Using the  directive under Apache 1.1 (or greater) it
  161 is possible to restrict who is allowed to use these two debugging
  162 versions of cgiwrap.
  163 
  164 For example:
  165 <Location /cgi-bin/cgiwrapd>
  166 Order deny,allow
  167 Deny from all
  168 Allow from <your ip number here>
  169 </Location>
  170 
  171 <Location /cgi-bin/nph-cgiwrapd>
  172 Order deny,allow
  173 Deny from all
  174 Allow from >your ip number here>
  175 </Location>
  176 
  177 Depending on what value you place for allow from, you can control how
  178 widely these debugging versions
  179 are available.
  180      __________________________________________________________________
  181 
  182 
  183 Date: Sun, 7 Dec 1997 23:20:28 -0500 (EST)
  184 From: Yuji Shinozaki
  185 
  186 Look at the Rewrite rules.  You will need to activate mod_rewrite
  187 and recompile (see the Apache documentation and Configuration file:
  188 you will need to uncomment the follwing line and recompile.
  189 
  190 Module rewrite_module      mod_rewrite.o
  191 
  192 )
  193 
  194 For an example of the runtime configuration, in the srm.conf you could
  195 have:
  196 
  197 RewriteEngine on
  198 RewriteRule  ^/~([^/]+)/cgi-bin/(.*)    /cgi-bin/cgiwrap/$1/$2 [PT]
  199 RewriteRule  ^/~([^/]+)/cgi-bin-d/(.*)  /cgi-bin/cgiwrapd/$1/$2 [PT]
  200 RewriteRule  ^/~([^/]+)/nph-bin-d/(.*)  /cgi-bin/nph-cgiwrapd/$1/$2 [PT]
  201 RewriteRule  ^/~([^/]+)/nph-bin/(.*)    /cgi-bin/nph-cgiwrap/$1/$2 [PT]
  202 
  203 Which translates http://server.addr/~user/cgi-bin/program to
  204 http://server.addr/cgi-bin/cgiwrap/user/program. Also (in this example)
  205 http:/server.addr/~user/cgi-bin-d/program is translated to
  206 http://server.addr/cgi-bin/cgiwrapd/user/program, to provide debugging
  207 support.  And so on...
  208 
  209 The setup of cgi-wrap will determine where the scripts actually reside.
  210 (and I would actually put the script in a directory NOT in the
  211 usual public_html tree, because then it is possible for an anonymous user
  212 to read the cgi scripts).
  213 
  214 I have not implemented this to support virtual domains separately, but
  215 it should be possible.
  216 
  217 Hope this is helpful.
  218 
  219 yuji
  220 
  221 An alternative Action based execution tip Mr Yowler:
  222 
  223 Just a one-time contribution to your "Tips and Tricks" notes...
  224 
  225 The tip descibed by Shane DeRidder works nicely, except that he left out one im
  226 portant detail:  whatever path you set up, as the "Action" for "cgi-wrapper", m
  227 ust be defined in a "ScriptAlias" directive, so that Apache knows to run the cg
  228 iwrap executable,
  229 rather than treat it as static content.  Here is a sample from my own setup; a
  230 VirtualHost on a webserver that lives in a chrooted environment:
  231 
  232 
  233   ServerAdmin admin@somedomain.com
  234   DocumentRoot /
  235   ServerName www.somedomain.com
  236   ErrorLog /path/to/logs/www.somedomain.com-error_log
  237   CustomLog /path/to/logs/www.somedomain.com-access_log
  238   ScriptAlias /cgi-bin/ /serverwide/script/path/
  239 
  240     UserDir public_html
  241 
  242 
  243    AllowOverride AuthConfig Limit
  244    Options Indexes Includes ExecCGI
  245    Action cgi-wrapper .cgi
  246 
  247 
  248 
  249 This configuration allows users within the www.somedomain.com site, run .cgi sc
  250 ripts, from wherever they want, within their home directories.  It's is relativ
  251 ely transparent, as Shane DeRidder said, execpt for two things:
  252 
  253 1) Any call for a script, that results in an error within CGIwrap (such as a ca
  254 ll for a script that does not exist), results in an error, from the CGIwrap exe
  255 cutable.  That error clearly labels itself as coming from CGIwrap, identifying
  256 to the user, that
  257 CGIwrappers are in place.
  258 
  259 2) Any attempt to password-protect access to the scripts, using the .htaccess m
  260 echanism, will fail, since the CGIwrapper is outside of the users' writable fil
  261 e system tree.  Ordinarily, the user's would simply .htaccess-control the direc
  262 tory containing th
  263 e script that they wrote.  With CGIwrap controlling script execution, however,
  264 Apache does not get an opportunity to check the .htaccess rules, for the script
  265  (it can only check rules for the CGIwrap executable, itself, and there aren't
  266 any, since it is o
  267 utside of the area that the users can modify), and therefore, any script that t
  268 he user intended to be password-protected or otherwise access-restricted, isn't
  269 .
  270 
  271 I suspect that a careful application of suEXEC would resolve the latter issue,
  272 though the cost of doing so, would be the loss of some of the cooler resource-l
  273 imiting functions of CGIwrap.  As for the former issue, well...  It would be po
  274 ssible to change t
  275 he CGIwrap source code, to display errors in whatever format suits the webserve
  276 r administrator, but is seems as though it would be a lot more effort than it's
  277  worth.  In my environment, I merely want to keep CGIwrappers transparent to th
  278 e users, to avoid
  279 breaking scripts that would otherwise work - I'm not actually trying to keep th
  280 e wrappers a secret...  :)  In fact, I would actually like them to take advanta
  281 ge of the debugging information that cgiwrapd offers them...  :)
  282 
  283 The symptom of failing to use ScriptAlias, on my system, was reflected in the A
  284 pache www.somedomain.com-error_log, as a "File does not exist: /serverwide/scri
  285 pt/path/~someuser/scriptname.cgi".
  286 
  287 Anyhow, that's my little contribution.  I am not on the mailing list (that's wh
  288 at I need - MORE email...  ), and I just had the one thing about the ScriptAlia
  289 s requirement, to add to the "Tips and Tricks" - otherwise I would have simply
  290 posted it to
  291  the mailing list.  I spent nearly a full day, tracking that one down... Don't
  292 I feel the idiot, now...  :)