[Tikiwiki-users] tiki 9.0: antibot capcha image 403 access denied

[Nick <oin...@le...>]

Hello,

I have a new Tiki 9.0 install.  I checked the user registration process worked -
it now has a capcha - good - but the capcha image is not visible.  So I can't
register!

I cut the image URL out of the webpage, and viewed it in isolation.  It has a
path in the form "/temp/public/<UUID>.capcha.png".

I get a "403 access denied".  I am not logged in, obviously.  My temp/.htaccess
file has:

 <FilesMatch ".*">
        order deny,allow
        deny from all
 </FilesMatch>

Whereas temp/public/.htaccess has:

 <FilesMatch ".*">
        order deny,allow
        allow from all
 </FilesMatch>

These are as installed by Tiki.

If I delete temp/.htaccess, I can view the image.  So it seems to be this which
is disallowing files in temp/public from being served, and this implies
temp/public/.htaccess isn't actually doing anything useful.

Refreshing my memory of how these things work, I read these:

  http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#order
  http://drupal.org/node/93865

Admittedly it's a bit subtle.  But it looks to me like the <FilesMatch ".*"> and
'allow from all'/'deny from all' directives are redundant and might not do what
they seem to do.

Ignoring what Tiki 9.0 has installed for me, I think what sounds like a correct
configuration would be to make use of the fact that .htaccess is inside an
implicit <Directory> section, and simply have:

temp/.htaccess:

  # deny access to this dir and children by default.
  Order allow, deny

temp/public/.htaccess:

  # allow access to this dir and children by default
  Order deny, allow

And if I put those in, it seems to work.  I can access
temp/public/<blah>.captcha.png, but not temp/README in my browser.

This *does* seem to be at odds with the fact that this prevents new user
registrations and that if the Tiki-installed defaults didn't work, it's likely
someone would immediately notice that!



Can anyone comment?  Am I the only person to see this?



Note, one possibly relevant fact is that my shared hosting (Eleven2) doesn't
actually use Apache, they use Litespeed (which is meant to respect .htaccess and
supports the usual Apache configs).  So far I've not noticed any funny behaviour
which suggests that it doesn't behave just like Apache.

Cheers,

Nick