At 03:07 PM 7/10/00 -0400, Shane Hathaway wrote:
"Phillip J. Eby" wrote:
Understood. I'll try to keep that use case in mind. Keep in mind, however, that being able to create a LoginManager is a pretty risky business in a portalish environment - you could potentially get access to somebody's password, since after all you will control an actual login screen! (Note however, that someone can create a phony login screen in DTML and bypass the entire Zope security model with a little "social engineering" anyway.)
I've thought of that as well. Perhaps we'll have to accept that the new model just doesn't lend itself to the area of configurable user databases.
I'm not sure which model you mean, here, but in any case I think the new security model is fine, *except* for the absence of a "root" user folder that is outside of Zope and is always present when you install Zope.
Well, I'm hoping you'll take a look at my Collector suggestion for a new Zope feature. :) Specifically, extending the "access" file to allow other "top-level" users to exist besides the superuser, who have roles defined in the file. There are many ways this would be useful, not the least of which is to break the "you need to do that at the next level up" problem. (Others include a simplified process for getting your Zope site set up, since you then don't have to login as superuser and add a user folder, then log back in as somebody else.)
If this were done, we could easily go to letting LoginManager objects be owned, since there'd always be a place "above" the LoginManager for the owner user to reside.
Hmm... this sounds like a good idea, but now that the ownership problem has been resolved in a way I didn't expect, the issue that motivated your idea is gone.
Maybe, maybe not. I think perhaps the most compelling argument from Digital Creations' viewpoint for having an expanded "access" file might be the simplification of the setup process for customers. And it would also make it easier to: 1) Phase out unownedness (user databases wouldn't need it) 2) Narrow the role of superuser (super-can-create hack can go away) 3) Do Zope virtual hosting and give somebody a Zope root and even superuser, while still being able to log in 4) Stop all the whining from people who want to know why superuser can't create or own objects any more. :)