REMOTE_USER in mod_rewrite lookaheads?

263 views
Skip to first unread message

Dave

unread,
Oct 6, 2011, 4:13:07 PM10/6/11
to mod_auth_pubtkt users
mod_auth_pubtkt is working great for me so far... but I have hit a
potential showstopper.

My application accepts a username as part of the URL:

http://www.myserver.com/appname/<username>/<date>

but also accepts a shortened version of the URL and uses mod_rewrite
to supply REMOTE_USER as the default username (along with some other
defaults) and redirect:

http://www.myserver.com/appname --> http://www.myserver.com/appname/dave/today

My RewriteRule, which has worked under "AuthType Basic", is:

RewriteRule ^/appname/?$ /appname/%{LA-U:REMOTE_USER}/today [R,L]

However, I'm finding that under "AuthType mod_auth_pubtkt", the
lookahead is failing for REMOTE_USER and the URL is being rewritten
as:

http://www.myserver.com/appname --> http://www.myserver.com/appname//today

(This is true whether I use "LA-U" or "LA-F" in the rule. I've also
tried turning on TKTAuthFakeBasicAuth.)

My web server is Apache/2.2.17 (Unix) mod_wsgi/3.2 Python/2.6.4
mod_auth_pubtkt/0.6 mod_apreq2-20090110/2.8.0 mod_perl/2.0.4 Perl/
v5.10.1

REMOTE_USER works just fine in my web applications (both mod_perl and
Python/Django apps) under mod_auth_pubtkt. It's only in the
mod_rewrite phase that I'm having a problem. At RewriteLogLevel 3,
the handling looks like this:

(3) applying pattern '^/appname/?$' to uri '/appname'
(2) rewrite '/appname' -> '/appname//today'
(2) explicitly forcing redirect with http://www.myserver.com/appname//today
(1) escaping http://www.myserver.com/appname//today for redirect
(1) redirect to http://www.myserver.com/appname//today [REDIRECT/302]

Ideas?

Manuel Kasper

unread,
Oct 10, 2011, 5:02:12 PM10/10/11
to mod_auth_p...@googlegroups.com
Hello Dave,

On 06.10.2011, at 22:13, Dave wrote:

> RewriteRule ^/appname/?$ /appname/%{LA-U:REMOTE_USER}/today [R,L]
>
> However, I'm finding that under "AuthType mod_auth_pubtkt", the
> lookahead is failing for REMOTE_USER and the URL is being rewritten
> as:

I've taken a quick look at the mod_rewrite source code, hoping to find out why the subrequest doesn't cause the REMOTE_USER variable to be set by mod_auth_pubtkt as desired, but couldn't spot the cause yet (I have to admit that I didn't have time to dig very deep so far...)

Perhaps you could do some more testing with further increased debug level (also in mod_auth_pubtkt: TKTAuthDebug 3 and LogLevel debug)? We might be able to find something in the logs then...

Regards,

Manuel

Dave

unread,
Oct 11, 2011, 4:10:27 PM10/11/11
to mod_auth_pubtkt users
Thanks, Manuel; I will set up conditions to capture some typical
requests. Rather than manually edit the log output to make it generic
(as I did above), or post real company data to the group, I would like
email you the log output at the email address on your Groups profile;
is that OK?

Dave

Dave

unread,
Oct 12, 2011, 8:16:23 PM10/12/11
to mod_auth_pubtkt users
Turning up the debugging output reveals that mod_auth_pubtkt isn't
even being invoked on these requests; if I just substitute
mod_auth_pubtkt directives in the same <Location> and <Directory>
blocks of Apache configuration where I was using different
authentication directives before, Apache doesn't apply them... a
request that matches one of these RewriteRules is handled without
REMOTE_USER being populated but doesn't generate any error_log
output. If I bump the mod_auth_pubtkt configuration up to a blanket
"<Location />" block, then the RewriteRules work as they did before
and mod_auth_pubtkt log output is generated. But the more specific
<Location> and <Directory> scopes that worked before do not.

I guess until I convince my Apache configuration that these requests
should be authenticated, I don't have any claim on your attention. If
I manage to get these requests to provoke some mod_auth_pubtkt log
output and REMOTE_USER still isn't being populated, I'll bug you.
(And if I can't, I'll just implement some logic in my application to
do the redirect I want, rather than continue to rely on mod_rewrite.)

Thanks.
Reply all
Reply to author
Forward
0 new messages