Re: Mixing rewrite with authn_dbd: Rewriting based on path value stored in mysql table

[Roman Medina-Heigl Hernandez <roman@xxxxxxxxxxx>]

Bob Ionescu escribió:
> 2009/5/11 Roman Medina-Heigl Hernandez <roman@xxxxxxxxxxx>:
>> Bob Ionescu escribió:
>>> 2009/3/2 Roman Medina-Heigl Hernandez <roman@xxxxxxxxxxx>:
>>>> The problem is that you cannot have %{REMOTE_USER} as 2nd parameters in
>>>> RewriteCond, so I have no way for comparing it with $1
>>> -didn't read all-; but you can compare it with a regEx internal backreference.
>>>
>>> RewriteBase /stats
>>> RewriteCond %{REMOTE_USER}<>$1 !^([^<]+)<>\1
>> Could you explain that, please? I didn't know that syntax...
> 
> You're capturing a value with ^([^<]+), that is according to our test
> string the value of %{REMOTE_USER} followed by the two characters <>
> as a unique separator followed by the (previous) match of ([^<]+)
> which matches against the value of $1.
> 
> E.g. if the remote_user is foo, the regEx will match against a test string of
> foo<>foo
> 
> Just take a look at the manpage of PCRE, http://www.pcre.org/pcre.txt section
> BACK REFERENCES
>        Outside a character class, a backslash followed by a digit greater than

I knew (and have extensively used) about back references in PCRE but
thought the "<>" in RewriteCond's first arg could have a special meaning. I
didn't happen to figure out that you were simply "translating" REMOTE_USER
var to the second arg, using <> as separator. Nice trick!!!!!!

Anyway, I've fixed a bit by adding a slash character after REMOTE USER like
this:
RewriteCond %{REMOTE_USER}/<>$1 !^([^<]+)<>\1
(in order to avoid the bypass of the rewrite when you have authenticated as
"user" and the intruder is hacking/building URLs as "userrrrrrr").

>>> RewriteRule ^/clientes/(.*) /stats/%{REMOTE_USER}/stats/http/$1 [L]
>> Why did you removed PT and used L?
> 
> PT has no special effect in per-directory context (rewrite rules used
> inside <directory>/<location> containers, .htaccess files etc.). In
> fact mod_rewrite will add passthrough: to the result of your
> substitution, stop the processing of following rules in that set and
> remove passthrough: later w/o doing sthg. special. L will only stop
> the rewrite of the current set. I.e. the result is the same.

I removed [L] (is it a good practice to keep it? if not, I don't see the
need to keep it) and added additional protection so the user could only
visit the desired (stats/http) directory (in order to avoid the user
including its own username in the url and reaching other directories in its
home).

My final solution is:

                RewriteBase /stats
                RewriteCond %{REMOTE_USER}/<>$1 !^([^<]+)<>\1
                RewriteRule ^/clientes/(.*) /stats/%{REMOTE_USER}/stats/http/$1

                RewriteCond $1 !^[^/]+/stats/http/
                RewriteRule ^/clientes/(.*) hacking_attempt [F]


The alternative (adding L) is:

                RewriteBase /stats
                RewriteCond %{REMOTE_USER}/<>$1 !^([^<]+)<>\1
                RewriteRule ^/clientes/(.*)
/stats/%{REMOTE_USER}/stats/http/$1 [L]

                RewriteCond $1 !^[^/]+/stats/http/
                RewriteRule ^/clientes/(.*) hacking_attempt [F,L]

But I see no real difference between both solutions. Am I right?

Cheers,
-Roman

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
   "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx