[MKDoc-dev] Using cookie/ticket authentication rather than Basic Auth

[Charlie Garrison]

Good afternoon,

On 25/9/04 at 7:12 PM +0100, Chris Croome <chris at webarchitects.co.uk> wrote:

>Sounds good to me, I went to look at the mod_auth_tkt web site but
>it seems to be down at the moment: 
>
>  http://www.openfusion.com.au/labs/mod_auth_tkt/

Hmmm, I hope that is temporary. I was hoping for an Apache2 version of
mod_auth_tkt at some point. The module has changed hands before, so I doubt
it's really dead.

>It looks like a cool module, nice that it does this:
>
>  4. Drop-in replacement for Basic Authentication: mod_auth_tkt sets
>     the Basic Authentication REMOTE_USER environment variable on
>     authorised requests, so that existing scripts that work with Basic
>     Authentication should work unchanged in a mod_auth_tkt environment.

Yes, that was one of the main things that drew me to it. The other was the
ability to function on frontend apache (without modperl) as well as have a
perl API. The app I was working on at the time used basic http auth, and users
were reporting problems with logging off (especially from public computers)
since quitting the browser was often confused with closing the window. I
needed a way to guarantee logging out, and mod_auth_tkt solved that nicely.
And I have since used it for many other projects so it's part of my routine.

>>So I just need to know whether I should make changes in the mkd
>>source tree, or create my own modules as subclass of MKDoc. Any
>>suggestions or opinions?
>
>Bruno might have some thoughts about the naming of perl modules and
>at some point if probably makes sense to look at reorganising all
>the naming and in the meantime your suggestion seems fine to me :-)

Speaking of names, I would love an introduction from people on this list. Do
you and Bruno both work for the company that developed MKDoc? How big is the
MKDoc community?

Bruno, let me know if you have any other naming suggestions for the
MKDoc::Auth modules I want to create.

>I'd be happy for this code to be in MKDoc perhaps the way it could 
>work is for there to be an option when a site is installed to
>select cookie or httpd authentication (perhaps the default should
>stay with http authentication)?

Yep, I agree with that. At the simplest, to switch between methods I figured
it would be a matter of changing the modules listed in the plugin conf file,
and changing the module assigned to the auth handler in httpd.conf.

>Or if mod_auth_tkt is installed and detected when the MKDoc site is
>being installed then there could then be an option for cookie
>authentication to be enabled? 

I hadn't thought about that, but sounds good. I always consider installation
to have a fair amount of manual configuration, so this would not be a priority
for me.

>Perhaps it might even be possible to offer HTTP authentication to
>clients when cookie authentication is the default but the client's
>browser is rejecting cookies? But if it isn't then this doesn't
>matter.

Yep, I had thought about that. The standard login script for mod_auth_tkt
already demonstrates doing a cookie test probe and giving an error page if the
browser fails. I don't see why that couldn't fall back to basic http auth
instead. I'm a bit rusty (as in never used before) on stacked handlers which
may be the way to get this working. So any input/suggestions on falling back
to basic http auth if cookies fail would be appreciated.

>If there is a variable that we can access in the templates based on
>which authentication method is being used they we can serve a login
>form via the login template fragment when it's needed for cookie
>authentication. 

I think that would be easy enough. Maybe the Handler::Authenticate*Tkt modules
could set a variable ($::AUTH_METHOD). The method called from templates would
return a value based on that variable (or a default value).

>The HTTP authentication support in 1.8 is a lot nicer than in 1.6,
>only one domain is needed, you can login, logout and also login as

I was slow to pickup on that change about only one domain needed. I mangled my
config slightly getting both domains working in 1.8. Once I got what was going
on though, I liked the improvement.

>another user and do all this without restarting your web browser,
>also there is an article about this here if people want to know how
>it works (though it might be a bit out of date):
>
>  http://wiki.slugbug.org.uk/HTTP_Authentication

Yep, I read that. Which is how I learned (& became impressed with) what MKDoc
is now doing for authentication. It's not 100% reliable though. I've got a
couple of browsers which don't handle new authentication requests properly.
For some reason one browser likes to keep reverting back to previous (must be
cached) authentication details. I'm using OSX and it could be related to the
use of keychain for storing authentication details. (Or the browsers handle
the request properly, but there are caching issues regarding which auth
details to send.)

>Some of the templates for the authentication need sorting out
>though, by default the templates from the module on CPAN is used and
>these don't match the new XHTML / CSS design. I'll look at fixing
>this next week.

What is the goal for changes in 1.8? How much of the code (& templates) from
mkd will be moving to packages listed on CPAN? What is the separation between
the MKDoc support modules on CPAN, and the 'app' modules in mkd?

Specifically in this case, where should I create the module for the login-tkt
plugin?

>Another thing that would be good to have in the medium term is
>support for HTTP digest authentication, there is this demo module
>for doing it with apache 1.3 here:
>
>  http://search.cpan.org/~geoff/Apache-AuthDigest-0.022/API/API.pm

I don't know much about digest authentication. But I figured if we do the
AuthTKT modules correctly, the same design can easily be used for any
substitute authentication modules. (I think that was already the plan though.)

>But it seems that it would probably be better to wait for mod_perl 2
>to become more stable, switch MKDoc to use apache 2.1 and then use
>this module, it looks very cool:
>
>  http://search.cpan.org/~geoff/Apache-AuthenHook-2.00_03/AuthenHook.pm

I wouldn't want to be *required* to use Apache2, at least not yet.

>One for the TODO list I think!

Yes. I may have some other suggestions for the TODO list as well. Eg. I
haven't been able to find a method which sanitizes cgi params, so creating a
method to verify all data passed in is needed (if it's not already there).


Charlie

PS. I have always worked in small (intimate) groups or (usually) alone. I
haven't taken such an active role in a open-source project before. So if there
are any basic rules of etiquette, etc. please let me know.
-- 
   Charlie Garrison  <garrison at zeta.org.au>
   PO Box 141, Windsor, NSW 2756, Australia