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
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
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
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
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
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
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 Systems
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
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
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
-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
-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
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.
-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
14 matches
Mail list logo
