[Zope-CMF] [dev] Unauthorized handling - a proposal
Charlie Clark
charlie.clark at clark-consulting.eu
Tue Apr 20 09:14:23 EDT 2010
Am 20.04.2010, 14:19 Uhr, schrieb yuppie <y.2010 at wcm-solutions.de>:
> Hi!
> Charlie Clark wrote:
>> Please add a separate folder for these views. We need to separate them
>> from the content ones.
> Why? 'browser' is a generic name, that folder is usually used for *all*
> browser views. Which folder names would you propose?
It makes it more manageable. Anyone looking at this for the first time is
likely to get a shock when trying to work out which views are where.
I'd like to have separate folders for "content", "login" or
"authentication", "workflow", etc.
>> BTW. (For pedagogic reason I'm not too keen on
>> EditForms being used when objects aren't being edited.)
> Why? Is this about names or implementation? EditFormBase is for all
> kinds of editable forms, ContentEditFormBase for content objects.
It's just about names. Providing consistency with the formlib heritage -
granted "PageForm" is not going to win any prizes for intuitive but I
think it's better than EditFormBase vs. ContentEditFormBase. I've always
associated ContentEditFormBase with IContentish
>> So +1 from me but as per my other e-mails - what will the CookieCrumbler
>> do afterwards?
>>
>> Using a view means that there is a hardcoded relation between the login
>> form and the login cookies.
> That doesn't have to be hardcoded. We could look up the cookie settings
> in the CookieCrumbler.
Would there be any advantage in this? CookieCrumbler doesn't seem to need
them itself if the authentication is handled in a view.
>> This is the current interface for ICookieCrumbler with proposed
>> deprecation decorators
>>
>>
>> class ICookieCrumbler(Interface):
>>
>> """Reads cookies during traversal and simulates the HTTP auth
>> headers.
>> """
>>
>> @deprecate auth_cookie = Attribute("""The key of the authorisation
>> cookie""")
>> @deprecate name_cookie = Attribute("""They key of the authorised
>> user
>> cookie""")
>> @deprecate pw_cookie = Attribute("""The key of the password
>> cookie""")
> Why deprecated? We can keep these 3 configurable and look them up.
Sure, keep them if there is a real benefit in the context of the CMF for
this.
>> persist_cookie = Attribute("""The key of the persistent cookie""")
>> local_cookie_path = Attribute("""If True, the cookie tied to the
>> local
>> path?""")
>> cache_header_value = Attribute("""If present, the login page will
>> not
>> be cached""")
>> log_username = Attribute("""If True, the username will in appear
>> in
>> Zope's log""")
>>
>> def delRequestVar(req, name):
>> """No errors of any sort may propagate, and we don't care
>> *what*
>> they are, even to log them."""
>>
>> def getCookiePath():
>> """Get the path for the cookie
>> the parent URL if local_cookie_path is True otherwise /"""
>> return path
>>
>> @deprecate
>> def getCookieMethod(name, default=None):
>> """ Allow overridable cookie set/expiration methods."""
>> return getattr(name, default)
> Why deprecated?
I'm assuming that this related to Methods that could be stored within the
CookieCrumbler when it was still a folder.
>> def defaultSetAuthCookie(resp, cookie_name, cookie_value):
>> """Set the authorisation cookie"""
>>
>> def defaultExpireAuthCookie(resp, cookie_name):
>> """Expire the cookie"""
>>
>> def _setAuthHeader(ac, request, response):
>> """Set the auth headers for both the Zope and Medusa http
>> request
>> objects.
>> """
>>
>> @deprecate
>> def modifyRequest(req, resp):
>> """Copies cookie-supplied credentials to the basic auth
>> fields.
>>
>> Returns a flag indicating what the user is trying to do with
>> cookies: ATTEMPT_NONE, ATTEMPT_LOGIN, or ATTEMPT_RESUME. If
>> cookie login is disabled for this request, raises
>> CookieCrumblerDisabled.
>> """
> Why deprecated?
I'm assuming that the login happens outside of CookieCrumbler. Please
correct me if I'm wrong on this.
>> def __call__(container, req):
>> """The __before_publishing_traverse__ hook."""
>>
>> @deprecate
>> def credentialsChanged(user, name, pw):
>> """# XXX: this method violates the rules for tools/utilities:
>> # it depends on self.REQUEST """
> Why deprecated?
Look at the docstring.
>> @deprecate
>> def _cleanupResponse():
>> """# XXX: this method violates the rules for tools/utilities:
>> # it depends on self.REQUEST"""
> +1 for deprecating (or maybe just removing) it
>
>> @deprecate
>> def unauthorized():
>> """Remove authentication cookies and redirect to standard
>> unauthorized"""
> +1 for deprecating (or maybe just removing) it
Let's bin the methods you are replacing.
>> @deprecate
>> def _unauthorized():
>> """Remove authentication cookies and redirect to standard
>> _unauthorized"""
> +1 for deprecating (or maybe just removing) it
>
>> @deprecate
>> def getUnauthorizedURL():
>> """
>> Redirects to the login page.
>> """
> +1 for deprecating (or maybe just removing) it
>
>> @deprecate
>> def logout():
>> """
>> Logs out the user and redirects to the logout page.
>> """
> Why deprecated?
Surely this should be handled directly by the logout form or view? If it
is kept to do the logging out, then the signature can be changed to
require the request to be passed in. Redirection should be handled by the
logout page.
>> def propertyLabel(id):
>> """Return a label for the given property id
>> """
>>
>> I'm more than happy to help with this if there is anything I can do that
>> doesn't mean you spend more time answering my questions than it would
>> take
>> to do the work!
> I'm only working on the login process. Could you perhaps start working
> on the logout process before we bring everything together?
Okay.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
More information about the Zope-CMF
mailing list