At 11:25 AM 5/16/00 -0400, Tres Seaver wrote:
Hmm, LoginManager might be able to exploit the "revert to unowned" behavior of objects belonging to former users:
* Create a temporary user temporarily;
* Assign it to REQUEST.AUTHENTICATED_USER;
* Construct the DTML Methods;
* Delete the user.
Oops, nope, this still won't work, because then the superuser won't be able to call those DTML Methods to add users (I think). Maybe leaving the "cruft" user in place is sensible, except that (for instance) it presents the same kind of problem as the recent piranha mess (default passwords). We could pass in the id and password of the new manager in the constructor form, I guess.
Maybe I'm missing something, but couldn't all this be solved by having objects created by the superuser always be owned by "nobody" with respect to ownership (not owner-role)? Wouldn't that fix this entire issue (and many others we probably haven't thought of yet)? (Please move follow-ups to zope-dev)