Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Dev

REMOTE_USER look-ahead in a "RewriteCond expr" ap_expr

 

 

Apache dev RSS feed   Index | Next | Previous | View Threaded


richard at daviesmail

May 29, 2012, 7:17 AM

Post #1 of 4 (657 views)
Permalink
REMOTE_USER look-ahead in a "RewriteCond expr" ap_expr

Hi all,

I'm trying to use the Apache 2.4 ap_expr syntax to write a complex test with
"RewriteCond expr". My test uses %{REMOTE_USER}.

However, the %{LA-U:REMOTE_USER} look-ahead syntax needed to access this
variable in a per-server context doesn't seem to work inside an ap_expr
- I get a parse error.

Can anyone help me understand how to test REMOTE_USER in a "RewriteCond
expr" test?

Thanks,

Richard.


sf at sfritsch

May 29, 2012, 11:14 AM

Post #2 of 4 (627 views)
Permalink
Re: REMOTE_USER look-ahead in a "RewriteCond expr" ap_expr [In reply to]

On Tuesday 29 May 2012, Richard Davies wrote:
> I'm trying to use the Apache 2.4 ap_expr syntax to write a complex
> test with "RewriteCond expr". My test uses %{REMOTE_USER}.
>
> However, the %{LA-U:REMOTE_USER} look-ahead syntax needed to access
> this variable in a per-server context doesn't seem to work inside
> an ap_expr - I get a parse error.
>
> Can anyone help me understand how to test REMOTE_USER in a
> "RewriteCond expr" test?

In a direct way, the answer is: not yet.

But it should be possible to capture the value with a regex and use it
as backreference $1 in an expr. Something like this (untested):

RewriteCond %{LA-U:REMOTE_USER} ^(.*)$
RewriteCond expr "... $1 ..."


Does this work?

Cheers,
Stefan


richard at daviesmail

Jun 15, 2012, 10:45 AM

Post #3 of 4 (598 views)
Permalink
Re: REMOTE_USER look-ahead in a "RewriteCond expr" ap_expr [In reply to]

Stefan Fritsch wrote:
> Richard Davies wrote:
> > I'm trying to use the Apache 2.4 ap_expr syntax to write a complex
> > test with "RewriteCond expr". My test uses %{REMOTE_USER}.
> >
> > However, the %{LA-U:REMOTE_USER} look-ahead syntax needed to access
> > this variable in a per-server context doesn't seem to work inside
> > an ap_expr - I get a parse error.
> >
> > Can anyone help me understand how to test REMOTE_USER in a
> > "RewriteCond expr" test?
>
> In a direct way, the answer is: not yet.
>
> But it should be possible to capture the value with a regex and use it
> as backreference $1 in an expr. Something like this (untested):
>
> RewriteCond %{LA-U:REMOTE_USER} ^(.*)$
> RewriteCond expr "... $1 ..."
>
> Does this work?

Hi Stefan,

Thanks for the idea and sorry for my delay responding - I went on holiday!

I've been trying to test this, and I don't think it works.

I believe that $1 would be a RewriteRule backreference, whereas we would
need a RewriteCond backreference %1 here:
http://httpd.apache.org/docs/2.4/mod/mod_rewrite.html#rewritecond

When I try those, I get errors like this:

RewriteCond: cannot compile expression " %1 -strmatch 'one'": Parse error near '%'

which look to me like %1 isn't supported in ap_expr?

Any other thoughts?


The exact test which I am trying to write would be:

RewriteCond expr "! %{REQUEST_URI} -strmatch '/${LA-U:REMOTE_USER}/*'"
RewriteRule ^(.*)$ /404.html [END]

i.e. only a logged in user X can access /X/* and other users get 404.

This is trying to support a very large number of users, specified in the
htdigest file, each of whom should only be able to access their own files.

Any other mechanism for achieving this kind of per-user directories would
also be welcome! I don't want to have to write thousands of different
valid-user statements for each different directory, and I can't use
mod_authz_owner since the users aren't system users.

Thanks,

Richard.


sf at sfritsch

Jun 15, 2012, 12:34 PM

Post #4 of 4 (616 views)
Permalink
Re: REMOTE_USER look-ahead in a "RewriteCond expr" ap_expr [In reply to]

On Friday 15 June 2012, Richard Davies wrote:
> I've been trying to test this, and I don't think it works.
>
> I believe that $1 would be a RewriteRule backreference, whereas we
> would need a RewriteCond backreference %1 here:
> http://httpd.apache.org/docs/2.4/mod/mod_rewrite.html#rewritecond

No, the syntax of ap_expr is distinct from the normal RewriteCond's
syntax. But it seems there is a bit of code missing that would make
the previous RewriteCond's backreferences available to ap_expr.
Currently it only works in the other direction.

> When I try those, I get errors like this:
>
> RewriteCond: cannot compile expression " %1 -strmatch 'one'":
> Parse error near '%'
>
> which look to me like %1 isn't supported in ap_expr?

But from your mail, I am not sure if it would actually be a good idea
to make those backreferences available as $1, ... It would probably be
rather confusing. I will have to think about a better solution.

> i.e. only a logged in user X can access /X/* and other users get
> 404.
>
> This is trying to support a very large number of users, specified
> in the htdigest file, each of whom should only be able to access
> their own files.
>
> Any other mechanism for achieving this kind of per-user directories
> would also be welcome! I don't want to have to write thousands of
> different valid-user statements for each different directory, and
> I can't use mod_authz_owner since the users aren't system users.

Without the return-404 bit, it's not that difficult with
mod_authz_core alone:

<RequireAny>
Require user workaround_for_PR_52892
Require expr "-n %{REMOTE_USER} && %{REQUEST_URI} -strmatch
'/${REMOTE_USER}/*'
</RequireAny>

Everything but the "Require expr ..." line is a workaround for
https://issues.apache.org/bugzilla/show_bug.cgi?id=52892

A solution with mod_rewrite is to use another indirection and put the
looked-ahead user into an envvar (untested):

RewriteCond %{LA-U:REMOTE_USER} ^(.*)$
RewriteRule ^ - [E=LA_USER:%1]

RewriteCond expr "%{REQUEST_URI} -strmatch '/${reqenv:LA_USER}/*'"
RewriteRule ^ - [R=404]

Apache dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.