On Sun, 2010-09-05 at 19:49 +0200, Laurence Rowe wrote:
> On 5 September 2010 18:47, Chris McDonough <chr...@plope.com> wrote:
> > On Sun, 2010-09-05 at 18:18 +0200, Hanno Schlichting wrote:
> >> On Sun, Sep 5, 2010 at 5:46 PM, Wichert Akkerman <wich...@wiggy.net> wrote:
> >> > On 2010-9-5 17:29, Hanno Schlichting wrote:
> >> >> PluggableAuthService
> >> >> ------
> >> >>
> >> >> There's tons of code based on this. I imagine we can first move the
> >> >> authentication API's into a WSGI middleware querying PAS as the
> >> >> backend.
> >> >
> >> > This sounds like the mistake repoze.who 1 made. It turns out that for
> >> > almost every use case you want more control over handling login
> >> > behaviour than WSGI middleware can provide. It is much simpler to have a
> >> > simple API to an AAA service and use that than to try pushing this into
> >> > middleware.
> >>
> >> Right, I'm aware of the repoze.who lessons. Authorization is always
> >> going to be a WSGI framework component ("endware") and not an isolated
> >> middleware. But there should be some subpart of the API, which allows
> >> you to share the same authorization information across multiple WSGI
> >> applications. Or deal with some of the external authorization
> >> handling, when you offload things to Apache or other SSO approaches.
> >>
> >> But I'm not familiar enough with this topic to know what exact subpart
> >> this is. It might come down to just the userid.
> >
> > r.who 2 actually allows you to dial responsibilities up and down. You
> > can use "full stack" middleware that lends it effectively the same
> > responsibilities as r.who 1, or you can use only the r.who "API" portion
> > in an app or you can combine the two approaches as necessary. See also
> > http://docs.repoze.org/who/2.0/narr.html#using-repoze-who-without-wsgi-middleware
> >
> > The particular pain point you should never run into, because it is truly
> > horrible: don't try to do any login form post handling in an
> > "identifier". Just allow the application to render a self-posting login
> > form and use "the API" to check credentials and set headers and so on,
> > rather than putting the login form handling itself into middleware
> > machinery. In particular, never do anything remotely like the
> > "RedirectingForm" plugin within
> > http://svn.repoze.org/repoze.who/trunk/repoze/who/plugins/form.py (it
> > wants to be the target for a login form post).
> >
> > Aside from that (which is a problem for people of any competence level),
> > most of the problems with the middleware approach stem from needing to
> > explain how the middleware approach works to integrators of widely
> > varying competence levels. Each has his own slightly varying
> > requirements, and each needs the middleware approach to be explained to
> > him within that context. This has been a truly painful task for me, but
> > that's more an indictment of my level of patience than it is of r.who or
> > things like it.
>
> I'm tempted to say that the login form should be a separate
> application end point to the CMS. Authentication is something that can
> and should be shared across multiple applications - it's much easier
> to maintain a number of smaller focussed applications than one large
> monolithic one.
Dunno. Not really even sure what that means. We tried to get
generality by putting a login form handler inside the "r.who
application", which arbitrary application code ("another application")
could post to. It failed because at the end of the day, login form
integration for arbitrary customers requires a lot of control over the
process from end to end; nobody is willing to give up any features (such
as login logging, arbitrarily skinned login form, arbitrarily complex
error messages, etc) to service the more general goal of
cross-application login (especially when they only have one application
anyway, understandably).
- C
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
