Am 20.04.2010, 16:21 Uhr, schrieb yuppie <y.2...@wcm-solutions.de>:
> You mean subfolders of browser? At the top level I would expect more
> than just the browser views inside folders with these names.
Well, yes. Best practice would be document/browser, etc. but I think it's
pragmatic to do something similar with the browser views that we already
have with default skin: zpt-content, zpt-generic. I assume any suggestion
is likely to be greeted by a collective shrug from everyone else,
> For now I'll keep it where it is. If we agree on a new structure, things
> can be easily moved around.
Indeed.
>>>> 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.
> For now I plan to move less out of CookieCrumbler than you seem to
> expect.
I'm guilty of quite a few assumptions which is why I created the interface
and dropped in here for discussion.
>>>> @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.
> Could be. +1 if you are sure it is useless.
I'm not sure on any of this. CookieCrumbler isn't clear on many things.
>>>> @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.
> For now I just want to remove these lines from __call__:
> @@ -261,12 +260,6 @@
> if req.get('disable_cookie_login__', 0):
> return
> - if (self.unauth_page or
> - attempt == ATTEMPT_LOGIN or attempt == ATTEMPT_NONE):
> - # Modify the "unauthorized" response.
> - req._hold(ResponseCleanup(resp))
> - resp.unauthorized = self.unauthorized
> - resp._unauthorized = self._unauthorized
> if attempt != ATTEMPT_NONE:
> # Trying to log in or resume a session
> if self.cache_header_value:
Thanks for the clarification.
>>>> @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.
> But is it obsolete?
I don't know - it only seems to have relevance in the final statement of
__call__
>>>> @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.
> Right. If you write a view for that, the method might become useless.
But that itself would imply the logout view becoming the default action.
We can keep it around for access from untrusted code.
I'll update the interface to reflect this discussion.
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
_______________________________________________
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
