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

Sun Sep 26 14:06:43 BST 2004

Hi

On Sun 26-Sep-2004 at 01:02:05PM +1000, Charlie Garrison wrote:
> 
> 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.

Yep, it's probably just resting ;-)

> 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?

Yes Bruno, me Adam and Laura work for MKDoc at the moment, others
have in the past. Bruno does most the sys admin type stuff and I do
mostly information architecture and web design. There is some more
info about us here (though the objectives text on this page needs
re-writing):

  http://www.webarchitects.co.uk/about/

I don't think the MKDoc community is very big at the moment -- it's
only just been GPL'ed. The templating system, Petal, has more of a
community around it since it's been Free for longer. Hopefully, as
more people start using MKDoc, it will grow :-)

> 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.

That sounds fine.

> >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.

OK, then we can just leave it defaulting to HTTP authentication for
the moment but have the code and config variables in place for
switching it over.

> >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).

That sounds good to me.

> >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.)

Ah, which browsers? I know there are a load of problems with the
last version of IE for Macs, though thankfully MS have now
abandoned that browser...

> >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?

Good question!

Jean-Michel's plan was to have Free libraries on CPAN and for MKDoc
to be a proprietary application that depended on these, but now this
has changed and everything is under the GPL.

So there is no longer a need to have a seperation between these
things and I don't see why it can't all go on CPAN.

One thing that we perhaps need to consider is the license,
everything on CPAN is under the GPL and the artistic, the same terms
as Perl itself, everything else is just under the GPL.

It probably makes sense for everything that does go on CPAN to be
under the same terms as Perl, this is what the FSF seems to suggest:

  License of Perl

  This license is the disjunction of the Artistic License and the
  GNU GPL--in other words, you can choose either of those two
  licenses. It qualifies as a free software license, but it may not be
  a real copyleft. It is compatible with the GNU GPL because the GNU
  GPL is one of the alternatives.

  We recommend you use this license for any Perl 4 or Perl 5
  package you write, to promote coherence and uniformity in Perl
  programming. Outside of Perl, we urge you not to use this license;
  it is better to use just the GNU GPL.

  http://www.fsf.org/licenses/license-list.html#PerlLicense 

> >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.)

Yep :-)

The neat thing about digest authentication is that it is secure
enough for editing open web sites (no plain text passwds) via HTTP
and therefore HTTPS doesn't need to be used for sites where there is
a desire for no plain text passwds to be flying around the network.

But it does look like it's something that will have to wait for
apache 2...

> >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.

I agree.

> >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).

Great. We will set up a http://mkdoc.org/ site and move the
documentation off the .com site and also open this site up to the
community -- this would be a good place to keep TODO lists and the
like :-)

> 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.

You are doing fine :-)

I think we should be OK making it up as we go... ;-)

Chris

PS I'm going out to get some fresh air now, I'll reply to your other
emails later :-)

-- 
Chris Croome                               <chris at webarchitects.co.uk>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/   