Bob Ionescu escribió:
> 2009/5/11 Roman Medina-Heigl Hernandez <ro...@rs-labs.com>:
>> Bob Ionescu escribió:
>>> 2009/3/2 Roman Medina-Heigl Hernandez <ro...@rs-labs.com>:
>>>> 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-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
