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
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 out if an
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
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 later
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 currently
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 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 for
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.
[...]
On Mon, 2011-10-17 at 11:44 +0200, Christian Hilberg wrote:
I take it this new password API deals with IMAP|POP|SMTP|... 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 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 IMAP|POP|SMTP|... service
passwords _only_, i.e. service user authentication?
Correct. I don't have a good
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
11 matches
Mail list logo
