On Thu, 2004-09-02 at 12:38, Lennart Regebro wrote:
> ...

> Then, suggestion:
> =================
> My tests seems to show that inserting a return after the unauthorized 
> call above:
>              if user is None and roles != UNSPECIFIED_ROLES:
>                  response.unauthorized()
>               return
> will solve this issue. It is now possible to NOT raise an exception in 
> unauthorized and still not get problems. Instead, you can now to a 
> RESPONSE.redirect(), or you can replace the body with setBody for a 
> login form, or something like that.
> I haven't been able to find any other code that continues after an 
> unathorized call, so this should be the only place. Also, during normal 
> operation, it is obvuiosly a safe bet. The change in itself has no nasty 
> side effects.

I'd add a transaction rollback before return actually, which is the
normal behavior when an exception is raised like Redirect or

So if the situation is: user is anonymous or has insufficient rights
on a object which is handled after some changes are made to objects,
the challenge will take place and rolls back all these changes which
should not have taken place for that user.


             if user is None and roles != UNSPECIFIED_ROLES:

should do the trick.

Tino Wildenhain

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to