>From: Erdmut Pfeifer <[EMAIL PROTECTED]>
>Subject: Re: Authentication handlers
>
>On Mon, Mar 05, 2001 at 10:28:15AM +1100, Sisyphus wrote:
>>
>>
>> ----- Original Message -----
>> From: Pierre Phaneuf <[EMAIL PROTECTED]>
>> To: modperl <[EMAIL PROTECTED]>
>> Sent: Monday, March 05, 2001 9:29 AM
>> Subject: Re: Authentication handlers
>>
>>
>> > Cees Hek wrote:
>> >
>> > > So instead of storing a y/n in the database, store a unique string that
>> is
>> > > used as the realm, and clear it when they log out. Now everytime you
>> send
>> > > the Authenitication required header, send the unique realm for this user
>> > > that you stored in the database, and if it doesn't exist, generate a new
>> > > one.
>> >
>> > Good one! The only bad thing I see is that the realm is visible in the
>> > dialog box the user see, isn't it? Seeing a random string might be a bit
>> > unsettling for the user, but there is no technical reason for it not to
>> > work.
>> >
>> > --
>> > Pierre Phaneuf
>> > Systems Exorcist
>>
>> Hi,
>> Are you guys sure about this ? I just tried it out and it doesn't work for
>> Apache1.3.12(win32) on win 98.
>> I visited a page in a 'basic authentication' protected directory, then
>> changed the name of the realm from 'htdocs access' to 'htdocs' but was still
>> able to access other pages in the same directory without being hit for
>> username and password. I tried hitting the back button and 'refreshing', and
>> I also visited another site in the interim. All to no avail.
>
>Hi,
>
>there are two things to consider here. First, the server really has to
>send the AUTH_REQUIRED + realm; second, the browser does have to honor
>that authentication request by asking the user for a new name/password.
>
>Typically, servers are set up not to send the AUTH_REQUIRED response
>code, when the browser already is sending a valid username/password
>combination. And that's where browser caching comes into play: having
>queried the user once for username/password, the browser associates it
>with that specific URL and automatically resends it for each subsequent
>request to that location (which usually makes sense as it avoids another
>round trip to the server).
>Now, what happens if the server is configured such that it sends an
>AUTH_REQUIRED, even though it did already get the basic authorization
>header? Well, as so often, it depends on the browser. Netscape, for
>example, does pop up a dialog box, asking for re-authentication, while
>IE simply resends the same old username/password combination again.
>Thus, in IE you don't get a chance to enter any new credentials for a
>certain location which you've already visited in the current browser
>session. M$ obviously thought that this would never make sense ;(
>(it effectively means that you have to restart IE, if you need to
>login anew...)
>
>I haven't yet tested this issue again to see what happens when bringing
>the "changing realms"-idea into play. Maybe an AUTH_REQUIRED + _new_
>realm would even convince IE to allow re-authentication... ;)
>
>Erdmut
Hi,
Cees suggestion seems to unlock part of the browser behaviour puzzle
that we are trying to solve to meet the following requirements for a
PerlAuthenHandler:
*URL based session handling if cookies not enabled,
*LDAP authentication,
*Force reauthentication if given inactivity period passed,
*Maintain state information in main memory, no DBI store required.
So now our session state information is "Time_last_accessed and Next_realm",
or generate the realm based on current time if inactivity period lapsed.
Assuming that we are sending an AUTH_REQUIRED when inactivity period is
lapsed.
Now what PerlAuthenHandler's do we build on that come closest to this
design?
Apache::AuthCookieURL and extend to include inactivity modifications
+ memory management like in Eagle book pg. 222
Apache::AuthenLDAP
and use them together as stacked handlers.
Go easy on me, it's my first mod_perl posting but have been chewing on
the mod_perl guide, eagle book, and the mailing list archives.
--
Daryl Campbell The magician tried to blame it on the rabbit,
Athabasca University pulled her out of the hat couldn't make her disappear
(780) 675 6379 ...never more blind than when looking at ourselves
[EMAIL PROTECTED] Bob Kemmis, Kemmisutra
