If a Wikimaster wants to apply different authorization schemes to different Wikiwebs he/she should:

• replicate the bin directory for each scheme.
• enable the directory by means of a ScriptAlias directive (this step is not needed if all bin copies are subdirectories of the same _ScriptAlias_ed directory)
• set a new .htaccess file in the new directory
• where possible, use symlinks to keep all wikiwebs synchronized

Do you have suggestions?

-- AndreaSterbini - 04 Oct 1999

That is certainly possible. It might be easier to use just one bin directory and modify the .htaccess to grant different permissions per web. I have not tried it but it should be possible to specify the web, e.g. use <Files "edit/Myweb"> instead of <Files "edit"> .

Permissions could be based on groups if needed, e.g. use require group myGroup instead of require valid-user .

-- PeterThoeny - 05 Oct 1999

Sorry, I have tried and this does'nt work. The <Files "edit/Myweb"> rule does not fire because the <files> directive applies only to files in the local filesystem (edit/Myweb is not a file).

To make an acces rule that works at the URL level (as the "edit/Myweb" is) you must use the <Location "edit/Myweb"> directive.

Unfortunately, this directive MUST be placed inside the main access.conf file.

To use a local .htaccess file use the above way ( bin directory replication).

-- AndreaSterbini - 08 Oct 1999

A quick simple way would be to have the login that generated a random url session key and stored it in a file or database. The session key identifies the user, which can be check against a file, say topic.auth, with a list of authorised users.

This would require a auth checks to be tiggered before views/edits/whatever. Maybe by putting something like:

 if( ! &wiki::webAuth( $webName, $sessionKey ) ) {
        $tmpl = &wiki::readTemplate( "noauth" );
        $tmpl = &wiki::handleCommonTags( $tmpl, $topic );
        print $tmpl;
        return;
   }

More complex stuff would probably require redesign.

-- NicholasLee - 18 Jan 2000

Here is the instruction on how to perform authorization on a per web basis:

• move /home/httpd/twiki to /home/httpd/realtwiki

• edit wiki.cfg so that all but $wikiHomeUrl now points to /realtwiki, while $wikiHomeUrl points to /twiki (without bin, it is not needed):

    
   #                   /cgi-bin/view/Main/WebHome : link of TWiki icon in upper left corner :
   $wikiHomeUrl      = "http://kurt.poggiosecco.it/twiki";
   #                   Host of TWiki URL :    (Example "http://myhost.com:123")
   $defaultUrlHost   = "http://kurt.poggiosecco.it";
   #                   /cgi-bin : cgi-bin path of TWiki URL:
   $scriptUrlPath    = "/realtwiki/bin";
   #                   /p/pub : Public data path of TWiki URL (root of attach$pubUrlPath       = "/realtwiki/pub";
   #                   Public data directory, must match $pubUrlPath :
   $pubDir           = "/home/httpd/realtwiki/pub";
   #                   Template directory :
   $templateDir      = "/home/httpd/realtwiki/templates";
   #                   Data (topic files) root directory :
   $dataDir          = "/home/httpd/realtwiki/data";             
   

• in httpd.conf change all references to /twiki to /realtwiki, and add

 
    RewriteEngine on
   #edit,preview,save,attach,upload are autheticated on a web basis
   RewriteRule /twiki/(edit|preview|save|attach|upload)/(.*)$ /realtwiki/data/$2/$1
   #all others are free
   RewriteRule /twiki/(.*) /realtwiki/bin/$1
   </LocationMatch>
    

• in /home/httpd/realtwiki/data/Main/.htaccess

   AuthUserFile /home/httpd/realtwiki/data/.htpasswd
   AuthName ByPassword
   AuthType Basic
   
   require valid-user
   RewriteEngine on
   RewriteRule ([^/]*)/([^/]*) /realtwiki/bin/$2/Main/$1
   

• repeat for all other webs.

Clearly, in order to have different access controls one has to refer to different .htpasswd files.

One should also change register: it should be called with the name of the web as its argument, read the .htaccess file and alter the referred .htpasswd.

In this way one has a flexible setup: by referring to the same .htpasswd file the situation is the same as at present, by using different .htpasswd one can discriminate the accesses.

-- FrancoBagnoli - 03 Sep 2000

My solution to this has been similar to the one I laid out in LockedPages -- I add a Web-level preference called ALLOWED. This is a comma separated list of allowed users for this Web. That means you should lock out the ALLOWED variable as I describe in LockedPages. Then you can add this code to wiki.pm (right at the end of initialize (well -- before the return, of course). (You also need the noauth template).

    my $ulist = "";
    $ulist=&wiki::getPrefsValue("ALLOWED");
    if ($ulist ne "") {
      if ($ulist !~ /(^|(\s+))$userName\s*(,|$)/) {
        my $tmpl="";
        print("content-type:text/html\n\n");  # not always necessary but how to do otherwise?
   $tmpl= &wiki::readTemplate( "notauth" );
   $tmpl = &wiki::handleCommonTags( $tmpl, $topicName );
   print $tmpl;
        exit 0;  # stop right here!
        }
      }

This works very well, but there are two problems I know of.

• You must authenticate the user at all times (even for view) if this is going to work. TWiki does not know who you are unless everything is authenticated. If you just want to limit editing, use the scheme in LockedPages but make everyone an "Admin" for that Web(or at least change the test to make sure they have a name, but it doesn't matter what it is).
• Some scripts write their header before the call initialize and some write it after. Therefore, when it is time for initialize to write out the error script, it doesn't know if it should write the headers out or not.

My solution to the second issue was to write the header out so that it always works. But if you the user tries to hit a page that has already emitted headers, you see the error's header at the top of the error page. This is ugly, but in my case, I don't expect users to randomly guess the protected Web name anyway. Therefore, the error page is a rare occurance and I don't care if it is a little ugly.

You could fix this, of course, by modifying every file to either call initialize before (or after) the header output. Peter, what would you think of a global variable that tells you headers have been written? Might be useful for other things as well. I couldn't find such a variable.

-- AlWilliams - 15 Sep 2000