Z Object Publishing Environment

Search | Download | Documentation | Resources | Members




Join Zope.org
Log in

Developer Home
Get Involved!
The Fishbowl

 Zope Exits

Zope Newbies

page served by app2

Proposals Table of Contents Last edited on Jan 20, 2001 10:02 pm

I'd just like to point out that this proposal doesn't actually help with the issues brought up in UserProgrammableSecurityObjects, except for creating a root-level LoginManagerx, and that only if you don't have any kind of local roles computation. It doesn't fix local roles recursion or the encapsulation issue, so I would be wary of describing its scope as being an alternative to the things proposed in UserProgrammableSecurityObjects.

JimFulton (Aug 1)

I agree. It is only an alternative to the UserProgrammableSecurityObjects to the extent that UserProgrammableSecurityObjects solves this problem. :)

I also think we need to pay more attention to the issues raised in UserProgrammableSecurityObjects.

JimFulton (Aug 1)

I do like this proposal.

I'd like to see it kept simple. For example, I suggest that we keep the semantics of the access file the same but make it optional and don't create it on install. Disabling superuser should be as simple as removing or renaming the access file.

JimFulton (Aug 9)

I think that a way to address some of Phillip's concerns is to:

  • Make LoginManagerx, or something very much like it a part of Zope and have the bootstrapping process create the LoginManagerx such that it contains the initial user. Then people can use LoginManagerx facilities to provide additional user/validation sources.

PJE (Aug 9)

I don't have any objections to the idea of having a bootstrapped manager user, but I do think that that user still belongs outside the ZODB. Why? Well, what happens if you break your LoginManagerx and can no longer login? If you login as superuser and delete the LoginManagerx, now you're screwed because there is no way to repeat the bootstrap process. Unless of course you create some kind of API to do it with... Anyway, it seems to me you end up right back where you started: having to expand the access file or create another filesystem file in order to have a bootstrap user or user(s). It doesn't matter to me if you only allow one such user to exist, but I think that:

  1. Having the user inside the ZODB doesn't fix the problem, and

  2. Tying the bootstrap process to LoginManagerx is just as bad as tying it to UserFolderx. It's a kludge point that creates an awkwardness for non-developers. While the access file approach may require an improved editor for the file, it's a much more understandable setup step for a non-developer than are magical and mysterious automatically added users that then disappear if they should delete something accidentally.

Of course, I'm basing these impressions on not having a clear vision of how a ZODB-based bootstrap user would really work. If somebody wants to expand on that...?

View source UserBootstrappingDiscussion
Advanced Actions / History
Visitor: Anonymous User
Jump to:
... by pagename prefix or search term.
For a plain search:
Privacy policy       Printable Page       Feedback about Zope.org