Re: [Evolution-hackers] Camel Authentication Changes
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 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. Hi, I'm against this. I recall hearing from some users that their servers automatically lock user account after three consecutive failed authentication tries, thus what you suggest may easily mean that they will never login. It's better, from my point of view, to let user choose the right method to use. You know, I like to have my application under control, as trying to be smart doesn't always mean to be smart. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel Authentication Changes
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 password management more consistent and also make > life easier for providers. Now when a provider reaches the step where > it needs to authenticate, it simply calls: > > > gboolean camel_session_authenticate_sync (CamelSession *session, > CamelService *service, > const gchar *mechanism, > GCancellable *cancellable, > GError **error); 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. I tried this code, and the first thing it did was ask me for a password for my IMAP connection, even though that IMAP account uses a custom connection command 'ssh $mailhost /usr/libexec/dovecot/imap' so it gets a *preauthenticated* connection. (At other times, the custom command might have been something different like 'ssh $bastionhost openssl s_client -connect $internalserver:993' and the authentication *would* still have been required. You just can't know until you connect.) Even if the server asks for a password, with things like automatic NTLM authentication you can't know whether the automatic challenge/response will work. The old loop in the providers would handle that — it would try first with the empty password, then it would only prompt the user for a password if it really needed one. I think you've broken that in master now, because session_authenticate_sync() will just return immediate success if the SASL ->try_empty_password() method indicates that we can even *try* to authenticate without a user-provided password. > 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 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. > but it can also be NULL when not using SASL (such as for HTTP-based > backends). 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. All of the above issues have a single solution — we need to change things so that the password is requested *only* when we're actually connected to the server and we have discovered that we actually need it. I think the best way to handle it is to extend camel_service_get_password(), which is already called from the providers in the right place. If we make *it* trigger the password dialog, rather than doing the dialog in advance, then I think we solve all the issues. We'll also want to add a 'retrying' argument, for the caller to indicate that the last password it received was not correct. That'll prompt for actual user interaction, rather than just handing out the password from gkr, for example. > The CamelSession (or subclass) now handles all the looping. So if the > function returns TRUE, you're authenticated. If it returns FALSE, you > treat it like any other failed operation. You don't loop. Aside from the correctness issues, doing it internally can be a lot more efficient. Imagine you're on a slow connection and each DNS lookup, TCP connection establishment and SSL negotiation takes about 30 seconds. Now, do you want to connect a first time and work out that your stored password is invalid, then tear it all down and make a *new* connection, only to find that the user fat-fingered the password and you need to try a *third* time? Or do you want to keep the same connection open and issue three consecutive AUTH commands, looping *inside* the IMAP provider? There are similar considerations when the password changes during a session. TCP c
Re: [Evolution-hackers] Since evolution-alarm-notify asks for passwords
On Wed, 2011-10-19 at 16:57 +0530, Chenthill wrote: > Would it not be possible to store the password in gnome-keyring and be > shared. The other providers work this way, alarm-daemon would start > the authenticated calendars if it finds that the passwords is stored > gnome-keyring. It would also check whether the password can be > retrieved between intervals AFAICR. I'll investigate it further, but my point is that I store passwords, only the connection fails, because no VPN running, and I'm asked for a password, though the issue is not with password, but with server reachability. Might be an issue with evolution-mapi itself, maybe it forces password forget and thus it's lost even in this case. I'll see what I'll find there. (It seems like I should investigate first and then bring this on; I'm sorry). Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Since evolution-alarm-notify asks for passwords
On Wed, 2011-10-19 at 08:36 -0400, Matthew Barnes wrote: > One thing I wanted to add after all this account rewrite stuff is done > (maybe for 3.6) is support for VPN state. My thought was any place in > Evolution where you would enter host and port information there would > also be a check box item with a combo box listing all available VPN > connection names as configured in NetworkManager. Sounds good, though I'm not using NetworkManager to connect to my VPN. Again, I do not expect me being the only one :) Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Since evolution-alarm-notify asks for passwords
On Wed, 2011-10-19 at 08:36 -0400, Matthew Barnes wrote: > > My question is whether there can be done any better way of coping with > > this, because having the password prompts (there are two pilled, > > actually) after each and every login is just a bad experience, from my > > point of view. > (Gesticulating wildly about vaporware...) > One thing I wanted to add after all this account rewrite stuff is done > (maybe for 3.6) is support for VPN state. My thought was any place in > Evolution where you would enter host and port information there would > also be a check box item with a combo box listing all available VPN > connection names as configured in NetworkManager. +1 +1 +1 That would be awesome [being able to associate an account to either 'general' network status or a specific VPN connection / Network profile]. I have accounts that only work with the VPN up; and it is irritating sometimes when Evo insists on trying to access them when no connectivity is available. > Something like: >[x] Requires an active VPN connection to [ My Company's VPN |v] > The VPN ID would get stored in the data source's key file. +1 + 1 +1 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Since evolution-alarm-notify asks for passwords
On Wed, 2011-10-19 at 08:24 +0200, Milan Crha wrote: > I cannot find the thread where this was discussed, I'm sorry, but after > few days I found why this behaviour is pretty bad and why the > evolution-alarm-notify didn't ask for passwords. My usecase is pretty > simple, and I believe there are many corporate users with the same > environment: I have entered few calendars which are accessed only when > I'm connected to company vpn, unless they fail. When I login I do not > have the vpn running, thus I'm asked for my passwords, thus I connect to > vpn and then enter it (it's not prefilled, because it's not a reprompt, > though maybe some little change on evolution-mapi could be done - these > are evo-mapi calendars). > > My question is whether there can be done any better way of coping with > this, because having the password prompts (there are two pilled, > actually) after each and every login is just a bad experience, from my > point of view. (Gesticulating wildly about vaporware...) One thing I wanted to add after all this account rewrite stuff is done (maybe for 3.6) is support for VPN state. My thought was any place in Evolution where you would enter host and port information there would also be a check box item with a combo box listing all available VPN connection names as configured in NetworkManager. Something like: [x] Requires an active VPN connection to [ My Company's VPN |v] The VPN ID would get stored in the data source's key file. Then the backend for that data source would be treated as offline until Network Manager broadcasts an active VPN connection whose ID matches what you've selected. And I believe we're already smart enough to not show password prompts for offline backends. I think monitoring NetworkManager (and the other network tools we support) is going to be another job for the evolution-source-registry service rather than Evolution, for this very reason you've described. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Since evolution-alarm-notify asks for passwords
On Wed, 2011-10-19 at 08:24 +0200, Milan Crha wrote: > Hi, > I cannot find the thread where this was discussed, I'm sorry, but after > few days I found why this behaviour is pretty bad and why the > evolution-alarm-notify didn't ask for passwords. My usecase is pretty > simple, and I believe there are many corporate users with the same > environment: I have entered few calendars which are accessed only when > I'm connected to company vpn, unless they fail. When I login I do not > have the vpn running, thus I'm asked for my passwords, thus I connect to > vpn and then enter it (it's not prefilled, because it's not a reprompt, > though maybe some little change on evolution-mapi could be done - these > are evo-mapi calendars). > > My question is whether there can be done any better way of coping with > this, because having the password prompts (there are two pilled, > actually) after each and every login is just a bad experience, from my > point of view. Would it not be possible to store the password in gnome-keyring and be shared. The other providers work this way, alarm-daemon would start the authenticated calendars if it finds that the passwords is stored gnome-keyring. It would also check whether the password can be retrieved between intervals AFAICR. In case a calendar is marked for alarms and if alarm-daemon was not able to retrieve the password, would it be a good idea to show a small warning icon in the panel, which could indicate the issue and mention that evolution needs to be started in order to retrieve the password ? Also inform the user that the password needs to be remembered for alarm-daemon to work fine. > Bye, > Milan > > P.S.: Most likely unrelated, but I see I'm asked for Tasks and Notes > passwords, at least based on the prompts, which should not be needed in > the evolution-alarm-notify, because evolution doesn't support alarms on > these. I dont think the earlier behaviour used to be like this. This should be a bug introduced at some state IMHO. - Chenthill. > > ___ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
