[pmwiki-users] How use lowercase in Group Names

[Joachim Durchholz]

Waylan Limberg schrieb:
> 
> I noted this issue when exploring the possibilities as well. I was
> sure there was some other way to format the rewrite rules in .htaccess
> to avoid this situation, but given the other factors I didn't really
> pursue it at the time. Anyway, later I came across another project
> that used an interesting approach to the rewrite rules. They were in
> part as follows (modified for PmWiki):
> 
> RewriteCond %{REQUEST_FILENAME} !-f
> RewriteRule ^(.*)$ phwiki.php?n=$1 [QSA,L]
> 
> The key is the "!-f" part which essentially means: 'If the requested
> file name does not exist use this rewrite rule, otherwise proceed as
> normal'.

Hmm... I see pros and cons for that.

On the pro side, you can structure your namespace simply by creating the 
appropriate files. Easy and convenient.

On the con side:

1. This gives access to all directories, even those that are supposed to 
be restricted... think wiki.d/Site.SideBar, which then anybody could 
download including passwords and all other attributes.
Passwords wouldn't be *that* large a problem if they are stored in 
encrypted form (I'm not sure about that), but you get the drift, I think 
:-).
The base reasons for that is that since PmWiki stores everything right 
in the DocumentRoot of the WWW server, the site admin needs to have a 
rather strict control over what's served and what isn't.

2. Creating a file might accidentally shadow a PmWiki page. This is an 
additional source of potential misconfigurations - whenever somebody 
says "oh my wiki doesn't accept changes on page Site.Sidebar", we'd have 
to ask whether he created Site.Sidebar in the installation directory. 
(Can actually happen easily enough if you use wget to check whether 
PmWiki will return a page in the first place. People have done more 
stupid things...)
So it would be *yet another* potential problem that we'd have to ask 
about to fix things.


A better strategy is to divide up the HTTP namespace according to some 
simple rule, such as:

* "Everything that starts with a lowercase letter should be served 
directly, everything else should go through pmwiki.php".
This is what the CleanURLs recipe does (or did when I last edited it *g*).
Note that this probably fails on issue #1 above (no time to check that 
out right now): it would serve wiki.d/SomePageWithASuperSecretPassword 
and anything else that's internal, as long as the name starts with a 
lowercase letter. (And I had thought that policy was sound...)
Issue #2 is handled nicely.

* "Everything that starts with an uppercase letter should go through 
pmwiki.php, everything else should be served directly"
This is what the CleanURLs recipe did before I started editing it.
It has the same problem as the previous approach, but in addition it 
makes it impossible to have PmWiki page names that start with a digit or 
punctuation. (Digits are particularly important, some punctuation could 
be useful too.)

* "Everything that starts with pub/ or pmwiki.php should be served 
directly, everything else should go through pmwiki.php"
Handles issues #1 and #2. Might serve less of the files you'd want to 
have served directly (but you can always place them in pub/, though that 
restricts the URL space a bit - OTOH you could add extra redirection 
rules if you really want those files served directly).

Hmm... seems like yet another opportunity to improve Cookbook.CleanURLs :-(

HTH
Jo