[Grok-dev] LoginDemo and PlainLoginDemo and BabyLoginDemo

[Luciano Ramalho]

On Jan 16, 2008 7:32 AM, Kevin Teague <kevin at bud.ca> wrote:
> Luciano, thanks for attempting to tackle the demonstration of
> authentication in Grok!

Hey, Kevin, thank you for joining in this effort!

> This is something that is still very hard to understand, especially if
> you are still new to a lot of Zope 3 concepts. The PAU implementation
> in Zope 3 was one of the first things that I learned in Zope 3 and it
> was fairly brain-hurtingly perplexing as an introduction to Zope 3
> authentication. As others have suggested, having something like a
> megrok.defaultauth that configures a sensible PAU would be a practical
> package for making it easier to add authentication to a Grok app, but
> I don't think it would make a very good demo application, as
> understanding how it works would require digging into the PAU
> interfaces and implementation.
>
> I've started working on another version of your LoginDemo called
> BabyLoginDemo tonight:
>
> http://svn.zope.org/Sandbox/kteague/BabyLoginDemo/

Cool, Kevin. I've read your code and learned quite a bit from it. It
makes a very good demo of how to implement a custom-built
authentication utility.

> The key to making an easy to learn authentication app I believe is
> that when you registar a local utility that provides IAuthentication,
> you only need to implement the IAuthentication interface. Also while
> you get a significant amount of complexity from PAU, since your login
> app does things like provide a count and sorted list of members based
> on specific configuration details for a PAU, this code wouldn't allow
> you to get any of the benefits of this complexity. i.e. when you do:
>
>      def members(self):
>          pau = getUtility(IAuthentication)
>          principals = pau['principals']
>
> You are relying on implementation details that are not part of the
> IAuthentication interface that you are asking for. If you added a LDAP
> authentication plug-in later on with something like:
>
>      pau['ldap_principals'] =
> ldappas.authentication.LDAPAuthentication()
>      pau['principals'] = PrincipalFolder()
>      pau.authenticatorPlugins = ('principals','ldap_principals',)
>
> Then code such as this would not work:
>
>       def members(self):
>          pau = getUtility(IAuthentication)
>          principals = pau['principals']
>          roster = []
>          for id in sorted(principals.keys()):
>
> Since you wouldn't be displaying any of the LDAP authenticated
> principals (which might be a good thing if your LDAP directory was
> very large ...)

I agree with your points above. But really my intent was not to show
off all the generality of PAU. All I wanted was to use an existing
authentication utilitity from the Zope 3 codebase, and one that used
the ZODB for storing account information and cookies for
authentication.

If I had to use a PAU to get that, there are two possibilities:
1) I'm not using the Zope 3 API in the simplest way possible (that
would be my fault, help would be appreciated)
2) the Zope 3 API makes this essential use case a bit convoluted (that
would be a problem with the Zope 3 API that we Grok developers should
address)

> In BabyLoginDemo I created a MemberAuthentication class that wraps up
> a cookie credential implementation and a reliance on a app['members']
> container to provide Member objects that also implement the required
> IPrincipal interface. Although you can join and login to BabyLoginDemo
> right now it's not finished you can't logout and member listing
> doesn't work yet ...

That is really nice and a very useful example, and I learned quite a
bit from it already.

But I would not call it BabyLoginDemo because if baby steps in Grok
authentication entail implementing your own authentication utility
from scratch, then I am afraid hordes of potential users will just run
away.

No matter how simple it is to bake your own authentication utility
(and I think this is a quality of Zope 3 you've demonstrated) the fact
remains that anyone who has used Django or Ruby on Rails expects these
things to be solved with a couple of lines of configuration.

So this leads to the question of who is the target audience for Grok.
Is it current Zope 3 users or is it web developers in general?

The tone of Martijn's tutorial tells me it's the latter. But to really
reach that audience Grok will need to provide a lot more in the way of
ready to use parts.

> Another package that might be interesting to create would be a PAU
> authenticator plugin that allowed you to configure it to treat any
> arbitrary grok.Container as an authentication source.

Sure, I'd like to use that in Kirbi for example, because in Kirbi each
user will have their own folder-like container of books, so it would
be natural to make the folder containing the user's folders an
authentication source.

Cheers,

Luciano