On Mar 1, 2005, at 8:46 AM, Mario Ruggier wrote:

> On Mar 1, 2005, at 1:48 PM, David Binger wrote:
>> Here's what we have instead of using NotLoggedInError.
>> I think the behavior the client sees is similar to what you describe
>> below,
>> in that there is no special login url.
>> We just call ensure_signed_in() anywhere where we are about to
>> expose information that requires authentication.
>>
>> def ensure_signed_in(msg="Please sign in."):
>>     import dulcinea.ui.user.signin
>>     if not get_user():
>>         page = dulcinea.ui.user.signin.SignIn().form(login_reason=msg)
>>         if not get_user():
>>             get_response().set_body(page)
>>             get_publisher().respond_now() # raises RespondNow,
>>
>> We have similar, but simpler functions "not_found()",
>> "invalid_query()", and "redirect()", all
>> of which set the response body, status, and headers as needed, and
>> then raise RespondNow.
>> Quixote doesn't need to have any knowledge about particular
>> application-level exceptions.
>
> The genericity of RespondNow and how it is handled is attractive. So
> you are basically putting the error specifics in the the preparation
> of the response object, prior to doing a respond_now. So, those error
> specifics have more of a chance of staying together in one place... ?

A better chance of staying together in the application programmer's
brain.

>
> What is not clear to me is what is the special role of Dulcinea here,
> other than serving as the utility that provides the source for the
> login page? Handling of RespondNow is done by the Publisher, entirely?
>

This is just an example of a respond-now function that happens to use
the Dulcinea signin form.
Applications could use these or else call their own functions for this
purpose.  The point is to
get the publisher out of the business of formatting these responses.

The publisher doesn't do any special handling of RespondNow, except
that it
catches the exception and then proceeds as if the traversal had
completed
in the usual way.

> ensure_signed_in() would still be called from a _q_access, typically?

It is reasonable to do that, but the MEMS Exchange applications are not
using _q_access
  anywhere.

>
> How would this scale to the situation of having several user roles,
> with different privileges, e.g. for an admin page being signed in
> would not suffice. This would just be an additional elif clause in
> ensure_signed_in(), that checks also the page's accessibility level,
> as well as the user's role/privileges, and what is set on the
> response?

We have a similar "ensure_admin_access()" that calls ensure_signed_in()
and then,
additionally, makes sure that the signed in user has the privileges we
require.

>
> So, in this scheme one would not need to subclass the Publisher to
> handle application-specific exceptions?

No.  The application supplies the functions that raise RespondNow.
The publisher just pushes the responses out.