Re: [Zope-PAS] Re: PlonePAS using SQL get AttributeError
Previously 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. The emergency user handling in PAS is very robust; I do not see how even a completely broken user folder at a higher level can break that. The main problem for Plone (and other frameworks/applications) is that if the root user folder is not a PAS you can get users objects which do not implemented the IPropertiedUser interface, which may break your expectations. I suspect that the best route forward, at least for Plone, is to just declare that acquisitioned users will work fine in the ZMI, but may not work when you are using the Plone interface. That will allow us to drop the code which replaces the root user folder. 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's an unneeded change to a critical object. If you can get away with not doing that you remove a possible risk of breakage. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope-PAS] Re: PlonePAS using SQL get AttributeError
On 4/19/07, Wichert Akkerman [EMAIL PROTECTED] wrote: The emergency user handling in PAS is very robust; I do not see how even a completely broken user folder at a higher level can break that. If the higher level user folder uses cookie authentication for example, and the emergency user exists on the root user folder. Since credentials are extracted in the higher level user folder and not passed on to the root user folder, the root user folder never gets a chance to authenticate the emergency user. The main problem for Plone (and other frameworks/applications) is that if the root user folder is not a PAS you can get users objects which do not implemented the IPropertiedUser interface, which may break your expectations. That's not as big of a problem as not being able to log in, right? 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's an unneeded change to a critical object. If you can get away with not doing that you remove a possible risk of breakage. I could argue against 'unneeded'. As for possible risk of breakage, it's as risky as using PAS for a non-root user folder. Since, as you mentioned, emergency user should work fine, I don't see any risk, right? If PAS is prone to breakage it should be made robust, period. It's a matter of 'do we trust our own software or not'. The impression I get from being on this list is 'oh you can use it, but there are no guarantees', 'if it breaks don't come complain to us, is not our fault'. Maybe it would be better *not* to recommend PAS at all. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope-PAS] Re: PlonePAS using SQL get AttributeError
Previously Sidnei da Silva wrote: On 4/19/07, Wichert Akkerman [EMAIL PROTECTED] wrote: The emergency user handling in PAS is very robust; I do not see how even a completely broken user folder at a higher level can break that. If the higher level user folder uses cookie authentication for example, and the emergency user exists on the root user folder. Since credentials are extracted in the higher level user folder and not passed on to the root user folder, the root user folder never gets a chance to authenticate the emergency user. Lets rephrase this: is the problem you see that the site user folder (which will be a PAS) issues a challenge, which results in credentials which the root user folder can not handle? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope-PAS] Re: PlonePAS using SQL get AttributeError
On 4/19/07, Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Sidnei da Silva wrote: Lets rephrase this: is the problem you see that the site user folder (which will be a PAS) issues a challenge, which results in credentials which the root user folder can not handle? Yes. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope-PAS] Re: PlonePAS using SQL get AttributeError
On Thu, 19 Apr 2007 08:16:25 -0400, Sidnei da Silva [EMAIL PROTECTED] wrote: On 4/19/07, Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Sidnei da Silva wrote: Lets rephrase this: is the problem you see that the site user folder (which will be a PAS) issues a challenge, which results in credentials which the root user folder can not handle? Yes. why wouldn't the root just fall back to its own default if it can't find credentials, like in the case of a standard zodb user folder at the root, basic auth? ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope-PAS] Re: PlonePAS using SQL get AttributeError
Previously Sidnei da Silva wrote: On 4/19/07, Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Sidnei da Silva wrote: Lets rephrase this: is the problem you see that the site user folder (which will be a PAS) issues a challenge, which results in credentials which the root user folder can not handle? Yes. But you can get that even with PAS if you change the challenger in your site PAS. For example if I configure my site to only allow OpenID logins you can no longer use the emergency user since no challenger will result in usernamepassword style credentials. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope-PAS] Re: PlonePAS using SQL get AttributeError
On 4/19/07, Kapil Thangavelu [EMAIL PROTECTED] wrote: why wouldn't the root just fall back to its own default if it can't find credentials, like in the case of a standard zodb user folder at the root, basic auth? It simply never gets a chance to do that IIRC. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope-PAS] Re: PlonePAS using SQL get AttributeError
Previously Kapil Thangavelu wrote: On Thu, 19 Apr 2007 08:16:25 -0400, Sidnei da Silva [EMAIL PROTECTED] wrote: On 4/19/07, Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Sidnei da Silva wrote: Lets rephrase this: is the problem you see that the site user folder (which will be a PAS) issues a challenge, which results in credentials which the root user folder can not handle? Yes. why wouldn't the root just fall back to its own default if it can't find credentials, like in the case of a standard zodb user folder at the root, basic auth? There is an interesting trick here. Suppose we have a configuration like this: - basic root user folder +- a site +- a PAS user folder which is configured to only handle OpenID you can not login directly with the emergency user on this site since the site will never issue a challenge which will provide a username and password which the emergency user authentication can use. But if you access the application root first that will result in a challenge being send which the emergency user authentication can handle. And once the session for that has been setup you suddenly will be able to access the site with the emergency user. Of course this assumes that you can access the application root outside the site. I do not think that is a bad assumption to make for someone who can setup the emergency user. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope-PAS] Re: PlonePAS using SQL get AttributeError
On 4/19/07, Wichert Akkerman [EMAIL PROTECTED] wrote: But you can get that even with PAS if you change the challenger in your site PAS. For example if I configure my site to only allow OpenID logins you can no longer use the emergency user since no challenger will result in usernamepassword style credentials. Correct. In the case of PlonePAS, we are just making the default, out-of-the-box config be not broken instead of being broken by default. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope-PAS] Re: PlonePAS using SQL get AttributeError
On Thu, 19 Apr 2007 08:33:16 -0400, Sidnei da Silva [EMAIL PROTECTED] wrote: On 4/19/07, Wichert Akkerman [EMAIL PROTECTED] wrote: But you can get that even with PAS if you change the challenger in your site PAS. For example if I configure my site to only allow OpenID logins you can no longer use the emergency user since no challenger will result in usernamepassword style credentials. Correct. In the case of PlonePAS, we are just making the default, out-of-the-box config be not broken instead of being broken by default. looking at this further, there really doesn't seem to be any good way to allow the root to be a non pas, and allow the plone default authentication (form based) to work with users in the root, without replacing the root. the way pas monkey patches the response during traversal, basically asserts only the inner most user folder gets a chance to challenge. apologies to the integrators, there really isn't a workaround for this outside of reworking pas's challenge mechanism or the challenge plugins to allow delegation up the chain, the means of which isn't apparent to me. -kapil ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope-PAS] Re: PlonePAS using SQL get AttributeError
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 possible). 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. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJ28s+gerLs4ltQ4RAodCAJ9DxmCBQD56IwjBesJwUwH8F/2ZMgCePr+d sEAWZQN6wAQLZ2otJV1BpLc= =WWAl -END PGP SIGNATURE- ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
[Zope-PAS] Re: PlonePAS using SQL get AttributeError
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sidnei da Silva wrote: On 4/19/07, Kapil Thangavelu [EMAIL PROTECTED] wrote: why wouldn't the root just fall back to its own default if it can't find credentials, like in the case of a standard zodb user folder at the root, basic auth? It simply never gets a chance to do that IIRC. That is a bug in whatever challenge plugin you are using, then. That does *not* happen with the standard challenge plugins (cookie / session auth), which arrange to add those credentials to the request in a form digestible as basic auth. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJ3T4+gerLs4ltQ4RAtKQAKCLMer9YKtYn2PgFFZ4IzOBjfrp2QCdF8xh zXCew2vFeEFu74nY+x4KNAQ= =4gdN -END PGP SIGNATURE- ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope-PAS] Re: PlonePAS using SQL get AttributeError
On 4/19/07, Tres Seaver [EMAIL PROTECTED] wrote: That is a bug in whatever challenge plugin you are using, then. That does *not* happen with the standard challenge plugins (cookie / session auth), which arrange to add those credentials to the request in a form digestible as basic auth. Wrong. That's exactly where the problem is, IIRC. They set request._auth, but at the time control is passed to the standard user folder, request._auth has already been bound to a local variable in BaseRequest.traverse(). -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
[Zope-PAS] Re: PlonePAS using SQL get AttributeError
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sidnei da Silva wrote: On 4/18/07, Kapil Thangavelu [EMAIL PROTECTED] wrote: my understanding is that part of the reason this was done, was laziness, on the part of the integrators, who didn't want to deal with the issues of having non pas users from the root acl browsing a plone site, and conditionally dealing with those the users within the plone code. i agree that its lame. Lame or not lame, it's been there for almost two years, and everyone complains but no-one came up with a better solution so far. Patches accepted, as usual. 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. Patient: Doctor, when I drink iced tea, I get a cold stabbing pain in my eye! Doctor: Take out the spoon first. That'll be $200, please. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJu6D+gerLs4ltQ4RAnH1AJ94+OTDmrvotF6/KLcfGFRy7m9pEgCgx2Xu VQUrtZinAs5pYkuVuFq3uow= =QdBL -END PGP SIGNATURE- ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
