[pmwiki-users] How use lowercase in Group Names
Joachim Durchholz
jo at durchholz.org
Wed Sep 28 15:06:12 CDT 2005
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
More information about the pmwiki-users
mailing list