This code was part of a module that was called post-auth. So my auth handler had already called the relevant methods... and thus the OLD way was working fine. This also worked in internal_redirect in mp1. Once upgraded to mp2... it appears that the internal_redirect did not get to the point in the auth module where get_basic_auth_pw was called... so suddenly I had this case where $r->user had no data.
Now, I can't say for a certainty (because I haven't taken the time to investigate, whether or not this means that the auth phase is skipped in internal redirects... but I did wonder. I'll probably look into this at some point in the near future. For the time, I just assumed that it was either is_initial_req skipping that... or potentially that I use worker/threaded apache/mp2... -----Original Message----- From: John Wittkoski [mailto:[EMAIL PROTECTED] Sent: Monday, July 12, 2004 5:59 PM To: Geoffrey Young Cc: Kreimendahl, Chad J; [EMAIL PROTECTED] Subject: Re: potential bug/issue with internal_redirect in mp2 Geoffrey Young wrote on 6/29/04, 6:28 PM: > > > OLD WAY: [broken] > > $obj->{USER_ID} = $r->user; > > $obj->{USER_PASS} = $I->get_basic_auth_pw; > > I'm not sure where you would have gotten this way from, but it is clearly > wrong - in both apache 1.3 and 2.0 it is ap_get_basic_auth_pw that > populates > $r->user (r->user in 2.0 and r->connection->user in 1.3). > > > NEW WAY: [fixed] > > $obj->{USER_PASS} = $r->get_basic_auth_pw; > > $obj->{USER_ID} = $r->user; > > yes, this has always been the correct way. > > subrequests (of which internal_redirect is one) have a rather clever > bug in > 1.3 - r->connection->user is global to the entire request, which includes > any subrequests. so, the "OLD WAY" would have worked for subrequests > in 1.3 > (though it should not have worked for the main request). see a post > from me > last week for more details on this exact issue. > > at any rate, this is not a mod_perl bug, or even a mod_perl feature - > it's a > feature of the apache API and there is nothing mod_perl can do about it. > > but thanks for bringing it up :) > Sorry, I know this thread is from a few weeks back, but I'm a little behind (as usual) and I wanted to ask for clarification. Isn't the ordering issue mentioned above only critical if you are coding your own authentication handler? (I don't know why you'd call get_basic_auth_pw outside of an authentication handler, but you might need to call $r->user outside of one.) If the current request was already handled by the built in Basic (or other basic password using) authentication handler, didn't that handler already call get_basic_auth_pw, so $r->user is populated for the remainder of that request? I ask because we have code that runs in a post-authentication phase that calls $r->user and it's always there, even for subrequests. That being said, I did notice that a few of the Apache::Auth* modules (that use the Basic auth mechanism to get the password) use is_initial_req to short circuit the authentication phase for sub-requests before they call get_basic_auth_pw, resulting in $r->user not being populated for post-authentication phases of subrequests unless they call it themselves. (Under 2.0 that is, since under 1.3 this is masked by the clever bug you mention.) --John -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
