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 Unauthorized 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. so: if user is None and roles != UNSPECIFIED_ROLES: response.unauthorized() get_transaction().abort() return should do the trick. Regards Tino Wildenhain _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )