[MKDoc-dev] Using cookie/ticket authentication rather than Basic
Auth
Charlie Garrison
garrison at zeta.org.au
Tue Sep 28 16:01:15 BST 2004
Good morning,
On 26/9/04 at 2:06 PM +0100, Chris Croome <chris at webarchitects.co.uk> wrote:
>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 :-)
I didn't realize you were responsible for Petal. I had looked at it a while
back and really liked it, but I had too much invested in HTML::Template to
bother switching. I'm enjoying the chance to work with it now.
>> >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.
And that's how I've got it working. It has uncovered another issue I hadn't
thought about. There are other templates/plugins that are hard-coded to use
Plugin::Login (and indirectly .login.html). So all the other templates/plugins
would need to be updated to also check which AUTH_METHOD is being used and act
accordingly. Or, the Auth::Handler::Authenticate and Auth::Plugin::Login
modules should delegate to to other modules. I was thinking along the lines of
the AnyDB module which uses the appropriate Berkely DB implementation.
I would need help with the logic/theory to create delegation for the Auth
modules. So suggestions would be appreciated.
On a related note, the translation strings for the sign-up and login
instructions need to be slightly different for the ticket based
authentication. Should I create new entries in the locale file? Where should I
look for instructions on working with locale files? I have not used them
before.
>>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...
Safari, OmniWeb and Mozilla. Mozilla's behaviour was erratic so I can't give
any useful comments. My use with Safari was very short-lived, but (from
memory) was very similar to OmniWeb (not surprising since they both use the
WebKit api). OmniWeb will successfully prompt for new authentication details,
and will load the next page correctly. But subsequent requests will revert
back to previous authentication details.
I didn't test very long. I noticed it wasn't working so just used Mozilla for
first my login id and OmniWeb for the second. I switched logins by switching
browsers.
>>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 :-)
Sounds like a good idea to me.
Charlie
PS. If I didn't make it clear above; I've got the ticket based authentication
working with MKDoc the way I wanted. I need to clean up some of the code
though before I submit the files.
--
Charlie Garrison <garrison at zeta.org.au>
PO Box 141, Windsor, NSW 2756, Australia
More information about the MKDoc-dev
mailing list