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 implementing the ->try_empty_password() > SASL methods for automatic NTLM auth, and I take my hat off to you for > finding a way through the mess. > > Having said that, I do think we need to adjust this approach to deal > with authentication as a *reactive* thing, not *proactive*. It *used* to > be reactive, but you changed it as a side-effect of your improvements. > > The point is that we authenticate ourselves *if* and *when* the server > asks us to. We cannot know in advance whether we're going to need a > password or not.
We discussed this at length on IRC last night and I'm still digesting all the implications of auth cases I hadn't considered. I'm hoping that, at least for the time being, we can get by with the current API with only some tweaks to the authentication loop logic. Down the road I'm perfectly happy to revisit this, and even break APIs if needed to do it right, but right now Red Hat is pressuring me to get this account rewrite branch of mine finished as quickly as possible. So for now I really have to move on from this. > That's fine at the moment, but the fact that we have to explicitly > choose *one* mechanism in advance ought to be considered a bug. In the > future, we ought to simply try *any* of the methods that the server > offers today, in some order of preference. So we could try Kerberos, > fall back to NTLM, etc. These changes seem to have made that harder to > fix. 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 auth attempt fails. It already kinda does that by looking up the CamelServiceAuthType struct associated with the mechanism name (if one was given) and checking its 'need_password' flag. If FALSE, it does ONE authentication attempt and bails on failure (instead of looping). After which you could possibly call camel_session_authenticate_sync() again with a fallback mechanism name. Problem is when a mechanism name is NOT given, as is the case for most HTTP-based backends, or when 'need_password' is TRUE, it assumes you'll *will* need a password to authenticate and prompts if one is not found in the keyring (which I understand now to be a bad assumption). That's the part that needs tweaking, for now. > It looks like it'll always ask for a password for HTTP-based backends, > but those have similar options; they may authenticate with Kerberos, or > with automatic-NTLM, or with cookies... or they *may* actually decide > that they need a password today. Right. I've made similar changes to the addressbook and calendar backends on my branch, more of which are HTTP based, and what I did there was first try to run some initial inconsequential operation ("list calendars" or some such) with no auth header at all, and if that fails with a "401 Unauthorized" *then* initiate authentication in a similar manner to camel_session_authenticate_sync(). I realize that doesn't cover all the use cases you were throwing at me, particularly the server password suddenly changing in the middle of a session, but perhaps that approach, in combination with the tweaking I mentioned above, would address the premature password prompt in EWS for the time being? _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers