-----BEGIN PGP SIGNED MESSAGE-----
Sidnei da Silva wrote:
> On 4/19/07, Tres Seaver <[EMAIL PROTECTED]> wrote:
>> I doubt you would take my patch, which would just rip the whole thing out.
>> The tradeoff (that users from the root acl_users get a "weird" or even
>> broekn experience when browsing in the Plone UI), would be far better
>> than stomping the root user folder, IMNSHO: really, that's an "iced tea
>> spoon" problem.
> The problem is not just the Plone UI. It affects anyone that uses a
> different challenge scheme at the root than at a more internal level.
> And the problem is not just 'broken experience'. You can't login *at
> all* with a user from the root user folder on an internal folder,
> depending on how you setup your site. That means you can *lock
> yourself out*. And not even the emergency user would work IIRC. That's
> *as unacceptable* to me as replacing the root user folder.
I haven't successfully locked myself out of the ZMI since before PAS
went into production. If you have a reproducible test case for this,
then lets fix PAS so that it can't happen.
If it *can* happen, then either the non-root PAS or one of its plugins
is broken (becuase a non-root PAS *has* to delegate to the root, no
matter what). If that means that some kinds of challenges can't be done
sanely without replacing the root user folder, then *document* that:
"IF you want to use the BazBam challenge model, you need to make your
root 'acl_users' a PAS and *put the plugin there*."
> I've repeated this a thousand times now. It only replaces the root
> user folder if it's a standard user folder, in which case PAS provides
> the *exact* same functionality of the standard user folder, and all
> the existing users are kept. It's essentially replacing six by
> half-dozen, and I just can't see anything wrong with that. I haven't
> seen any good justification of *why* that's a lame idea so far. 'It's
> lame because I said it is' doesn't cut it for me.
It is lame becuase:
- the Plone site *doesn't own the root*, and should never touch
anything outside its own site object.
- It is a kludgy workaround for a bug.
- it violates the Law of Least Surprise, and pisses off those
who trip over it. At a *minimum*, the UI which kicks this
off should inform the user that it will happen (by detecting
the "replaceable" folder). Not quite as minimally, it should
allow the user to opt out.
- it introduces the possibility of *more* bugs.
> I'm 36.842% sure that using a 'Delegating Multi Plugin' or some
> similar beast could avoid this. But when I tried to use the
> 'Delegating Multi Plugin' it was just plain unusable, and I've locked
> myself out. No one would mind a patch that implemented something like
> that as an alternative to replacing the the root user folder.
Lets work on that, instead of arguing further. I still need a recipe
for provoking the lockout (and one which uses only stock plugins, if
> Someone with minimal PAS knowledge can certainly come up with a
> configuration that allows users from the root user folder to login at
> more internal user folders. In fact, that should be the standard
> out-of-the-box behaviour for PAS.
I'll disagree: a non-root user folder is supposed to:
- return 'None' from a failed 'validate'. This is important,
because if the non-root folder "fakes" owning the user from
the root folder, that user will be unable to access protected
resources from outside the non-root's container.
- avoid grabbing sole control of the challenge process. This
is where the "user experience" comes in; trying to avoid the
basic auth prompt *at all costs* is evil in a non-root folder.
In order to make this work, challenge plugins may have to
fake basic-auth credentials into the request, so that the
root folder can still authenticate.
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-PAS mailing list