Re: [Zope-dev] Expanded access file (was Re: LoginManager patch consideredharmful)harmful)

2000-07-19 Thread Shane Hathaway

Chris Withers wrote:
 
 "Phillip J. Eby" wrote:
  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.  :)
 
 This sounds great, what happened about it?

You speak in the past tense.  This is only a suggestion and a
possibility. It's not as important as some other feature requests.

Shane

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




Re: [Zope-dev] Expanded access file (was Re: LoginManager patch consideredharmful)harmful)

2000-07-19 Thread Phillip J. Eby

At 10:15 AM 7/19/00 -0400, Shane Hathaway wrote:
Chris Withers wrote:
 
 "Phillip J. Eby" wrote:
  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.  :)
 
 This sounds great, what happened about it?

You speak in the past tense.  This is only a suggestion and a
possibility. It's not as important as some other feature requests.


Patch opportunity, perhaps?  :)  Ty and I would do it, no problem.  Heck,
I've been tempted to do it as a LoginManager function, since Zope doesn't
pay attention to anything past the first line of the "access" file...

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] Expanded access file (was Re: LoginManager patch consideredharmful) harmful)

2000-07-10 Thread Phillip J. Eby

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


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )