On Thu, 2011-10-20 at 12:50 -0400, Matthew Barnes wrote:
>
> I think we could achieve this with multiple calls to
> camel_session_authenticate_sync() with a different mechanism name each
> time ("kerberos", "ntlm", "login"), and making sure the session logic
> knows when to loop and when to bail o
On Thu, 2011-10-20 at 01:14 +0100, David Woodhouse wrote:
> This looks like a good idea, and cleaning up the various ways that the
> providers were behaving differently in that authentication loop (and
> calling directly out to the GUI) is a good thing.
>
> I looked at those recently when impleme
On Thu, 2011-10-20 at 01:14 +0100, David Woodhouse wrote:
> > The "mechanism" argument refers to the user's preferred SASL
> mechanism.
> > This will usually be taken from "url->authmech"
>
> That's fine at the moment, but the fact that we have to explicitly
> choose *one* mechanism in advance oug
On Sat, 2011-10-15 at 11:18 -0400, Matthew Barnes wrote:
> Just a heads up that I've changed Camel's authentication API to factor
> out the password loop that each and every provider currently replicates
> for themselves. Turns out they all have the same basic logic flow.
>
> These changes make p
On Tue, 2011-10-18 at 15:58 -0400, Matthew Barnes wrote:
> On Tue, 2011-10-18 at 21:29 +0200, Milan Crha wrote:
> > I'm currently trying to adapt evo-ews to current git master and this
> > change doesn't make much sense there, at least for me, because on the
> > first look there is used a libsoup
On Tue, 2011-10-18 at 21:29 +0200, Milan Crha wrote:
> I'm currently trying to adapt evo-ews to current git master and this
> change doesn't make much sense there, at least for me, because on the
> first look there is used a libsoup for authentications, thus no such
> auth_loop or any "same basic
On Sat, 2011-10-15 at 11:18 -0400, Matthew Barnes wrote:
> Just a heads up that I've changed Camel's authentication API to factor
> out the password loop that each and every provider currently replicates
> for themselves. Turns out they all have the same basic logic flow.
Hi,
I'm currentl
Hi Matthew,
Am Montag 17 Oktober 2011, um 23:48:01 schrieb Matthew Barnes:
> On Mon, 2011-10-17 at 15:21 +0200, Christian Hilberg wrote:
> > Fair enough, thanks for clarifying. If that's the current status, then
> > nothing is lost if we keep the implementation as-is for now and try it
> > again
On Mon, 2011-10-17 at 15:21 +0200, Christian Hilberg wrote:
> Fair enough, thanks for clarifying. If that's the current status, then
> nothing is lost if we keep the implementation as-is for now and try it
> again later on.
Still not sure how this whole security puzzle fits together yet, but
this
Hi there,
Am Montag 17 Oktober 2011, um 14:51:08 schrieb Matthew Barnes:
> On Mon, 2011-10-17 at 11:44 +0200, Christian Hilberg wrote:
> > I take it this new password API deals with service
> > passwords _only_, i.e. service user authentication?
>
> Correct. I don't have a good answer for you
On Mon, 2011-10-17 at 11:44 +0200, Christian Hilberg wrote:
> I take it this new password API deals with service
> passwords _only_, i.e. service user authentication?
Correct. I don't have a good answer for you on the security token PIN
use case at the moment.
_
Hi Matthew,
Am Samstag 15 Oktober 2011, um 17:18:27 schrieb Matthew Barnes:
> Just a heads up that I've changed Camel's authentication API to factor
> out the password loop that each and every provider currently replicates
> for themselves. Turns out they all have the same basic logic flow.
> [..
Just a heads up that I've changed Camel's authentication API to factor
out the password loop that each and every provider currently replicates
for themselves. Turns out they all have the same basic logic flow.
These changes make password management more consistent and also make
life easier for pr
13 matches
Mail list logo
