[Zope-PAS] Checked in the Challenge implementation.
mhammond at skippinet.com.au
Mon Sep 27 18:32:03 EDT 2004
> > 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>"
# Let each challenger have a go - but if any redirect,
# it is 'game over'
challengers = plugins.listPlugins( IChallengePlugin )
for challenger_id, challenger in challengers:
except Redirect, where:
HTTP challenge then is simply:
def challenge( self, request, response, **kw ):
realm = response.realm
# all challengers should 'addHeader' rather than 'setHeader' -
# The header needs to be aggregated for *all* challengers.
response.addHeader('WWW-Authenticate', 'basic realm="%s"' %
My challenger is similar - only sets the headers.
Redirection code now does:
raise Redirect, url
Does that sound reasonable? It certainly seems to clear up the semantics in
More information about the Zope-PAS