[Zope-PAS] Checked in the Challenge implementation.

[Mark Hammond]

> > No. The 1 means "do not continue with other plugins".
>
> which reason should drive a plugin to not allow
> other plugins? How should it know following
> plugins would just set some headers and are
> actually required?
> So user have to know and arrange all friendly
> plugins to be called before the 1 - setting one?
> And if they want to combine several plugins
> which each return 1 for some reason the auther
> finds apropriate? I expect a lot of headaches
> when people try to work this out :)

Wooohoo - thanks Tino - these are exactly my concerns.  And given I am
trying to work it out now, the logical conclusion is that I have alot of
headaches now.  The theory fits the proof :)

As a moderate proposal that reduces confusion for challenge/response
implementors, but tries to avoid the controversy of making redirect and
challengers truly interact:

# PluggableAuthServive challenge:
  def challenge(self, request, response):
   # Set the default status and body
   # This avoids each challenger trying to do it, and
   # provides a single place for l10n or 'skinning'
   m = "<strong>You are not authorized to access this resource.</strong>"
   response.setBody(m, is_error=1)
   response.setStatus(401)
   # Let each challenger have a go - but if any redirect,
   # it is 'game over'
   challengers = plugins.listPlugins( IChallengePlugin )
   for challenger_id, challenger in challengers:
       try:
           challenger.challenge(request, response)
       except Redirect, where:
           response.redirect(where)
           return

HTTP challenge then is simply:

    def challenge( self, request, response, **kw ):
        realm = response.realm
        if realm:
            # all challengers should 'addHeader' rather than 'setHeader' -
		# The header needs to be aggregated for *all* challengers.
            response.addHeader('WWW-Authenticate', 'basic realm="%s"' %
realm)

My challenger is similar - only sets the headers.

Redirection code now does:
        raise Redirect, url
rather than:
        response.redirect(url)

Does that sound reasonable?  It certainly seems to clear up the semantics in
my head.

Mark.