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

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.  :)

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to