<francesc.roma+catalyst@gmail.com<francesc.roma%2Bcatalyst@gmail.com>
>
I'm trying the new feature $c->req->remote_user introduced in 5.80005. I'd
like to know if it is possible to tell apache, in a .htaccess file, to not
ask authentication for a certain set of URIs (for example matching /public/)
I'm on a shared account in asmallorange.com ( apache 1.3.41). I'm using
fastcgi.
like to know if it is possible to tell apache, in a .htaccess file, to not
ask authentication for a certain set of URIs (for example matching /public/)
I'm on a shared account in asmallorange.com ( apache 1.3.41). I'm using
fastcgi.
I found a workaround for this scenario. Instead of setting up fastcgi in
.haccess at the root of the application, I make two different directories
for public and private, with different authentication rules. My directory
structure is like this
public_html/myapp/static (soft link to MyApp/static)
public_html/myapp/public
public_html/myapp/public/script (soft link to MyApp/script)
public_html/myapp/private
public_html/myapp/private/script (soft link to MyApp/script)
The .htaccess in the public directory is like this
AddHandler fastcgi-script .pl
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ script/myapp_fastcgi.pl/public/$1 [QSA,L]
Similarly in the private directory:
AddHandler fastcgi-script .pl
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ script/myapp_fastcgi.pl/private/$1 [QSA,L]
Auth stuf [...]
Also, in the static directory I could leave some things public ( css,
javascript, icons...) but make other private ( uploads, reports, ...) by
placing a .htaccess file requiring authentication in each corresponding
directory.
It's not a very flexible or elegant approach, but it seems to work.
Regards,
Francesc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090610/041ff91d/attachment.htm
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090610/041ff91d/attachment.htm