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/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
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 lo
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 username&password st
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
> >>(w
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 System
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 f
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
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 Sil
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 authenticatio
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 exist
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), wou
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 f
13 matches
Mail list logo
