After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 677007 - Add Basic authentication type
Add Basic authentication type
Status: RESOLVED FIXED
Product: evolution-ews
Classification: Other
Component: Miscellaneous / EWS Core
3.4.x
Other Linux
: High critical
: ---
Assigned To: Evolution EWS maintainer(s)
Evolution EWS maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2012-05-29 05:50 UTC by Milan Crha
Modified: 2012-07-13 07:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ews patch (24.42 KB, patch)
2012-06-05 10:43 UTC, Milan Crha
committed Details | Review

Description Milan Crha 2012-05-29 05:50:43 UTC
Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=821963

evolution-ews cannot connect to hosted Exchange 2010 server, which has disabled NTLM authentication, because latest libsoup (2.38.1) has fixed a bug about fallbacking to Basic authentication when NTLM fails. Dan Winship said in the downstream bug that the application should open a new session with NTLM disabled, if it wants to fallback to basic authentication. libsoup 2.36.1 is still with the "fallback bug", thus this was not a problem in previous versions.
Comment 1 Milan Crha 2012-06-05 10:43:33 UTC
Created attachment 215629 [details] [review]
ews patch

for evolution-ews;

I thought to add some "auto-fallback" into ews' code, but that's not good to do for two reasons:
a) it can be tricky
b) trying each authentication request twice, once with NTLM, the other time
   with Basic authentication can lead to account lock on servers which have
   set account locking policy after certain amount of unsuccessful logins.

Instead, this patch adds two Authentication types into mail account preferences, "NTLM" and "Basic", thus user can choose which to use. This, unfortunately, also required change in evolution [1]. I'm asking for string freeze break for gnome-3-4 branch of evolution-ews.

Please note that to have this properly working user might have patched evolution (will be part of 3.4.3) and currently: change the value in account's preferences, disable EWS account, close evolution, start evolution and enable EWS account with new authentication method set again. This way the book and calendar sources will also contain indication which authentication method to use.

[1] http://git.gnome.org/browse/evolution/commit/?h=gnome-3-4&id=72dab6f97c
Comment 2 cowardlysnake 2012-06-05 16:11:57 UTC
As I reported the downstream bug, if I can be any help testing this then please let me know.
Comment 3 Milan Crha 2012-06-06 11:53:00 UTC
Thanks, I appreciate it. Here [1] is a test build of evolution-ews with the patch included.

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=4132135
Comment 4 cowardlysnake 2012-06-06 19:00:25 UTC
OK - I created a new VM with Fedora 17 and applied all updates, rebooted and then installed the patched package. 

When I created the account I entered my email address and the Host URL, selected Basic from the drop down list and clicked Fetch URL.  The URLs were populated with my providers internal addresses not the external ones (as it did on Fedora 16) but I corrected them by hand. The password box that popped up when I click Fetch URL had the message "Enter password for myemail.com".

Unfortunately when I finished creating the account it appears to have immediately reverted to NTLM authentication.  A password box popped up with the message "Please enter the Exchange Web Services password for me@myemail.com on host myemail.com". I have verified that it is trying to use NTLM in the EWS_DEBUG=2 output and also by reopening the account preferences where the drop down list shows NTLM.

I've tried resetting the drop down in the account preferences back to Basic but it makes no difference.
Comment 5 Milan Crha 2012-06-07 17:18:05 UTC
Thanks for testing. I didn't highlight it much in comment #3, but the change in preferences requires fixed evolution, with this commit:
http://git.gnome.org/browse/evolution/commit/?h=gnome-3-4&id=72dab6f97

and I didn't build a package for it yet :( I'm currently building it here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4137306

With it installed, please follow the "hard account info change", as described in comment #3, at the last paragraph there.
Comment 6 cowardlysnake 2012-06-07 20:16:53 UTC
I tried installing the evolution package but it said I needed evolution-data-server > 3.4.2. I tried to install this from another task (http://koji.fedoraproject.org/koji/buildinfo?buildID=318742) but ended up in a mess - something to do with multilib.  

I've built a fresh VM and applied the test updates to see if that would give me the right dependencies to install.  I downloaded all the packages from the task in comment 5 and tried to install them all together but I got into trouble with Perl which is now newer than the version required by your packages.

I'm prepared to start from scratch again.  How do I get the correct version of packages to install this?
Comment 7 Milan Crha 2012-06-08 07:28:34 UTC
Thanks strange. I built my package against those in updates (not in updates-testing, except of evolution-data-server and gtkhtml3). Maybe if you try to install the rpms with yum with enabled updates-testing too, then it'll bring necessary packages. I would try something like:
   $ yum install --enablerepo=* evolution-3.4.2.-1.1...rpm evolution-ews-3.4.2-1.1...rpm

The evolution packages got marked for stable yesterday, and they will be available for regular updates soon, I guess in few days, till the change is propagated to all mirrors.

About the multilib issue, can it be possible you accidentally downloaded rpms for a different architecture that you have installed? Try with:
   $ uname -p
Comment 8 cowardlysnake 2012-06-08 19:43:46 UTC
All working now. Thanks very much! 

Your yum statement suggestion installed all the required dependencies and I could then install your packages from comments 3 and 5.

I had some trouble with contacts and calendar and I tried your suggestion in the last paragraph of comment 1 but this didn't fix it.  However, after a reboot it worked fine.

I'll wait a few days until the packages are available as regular updates and report back. 

A quick question - now it's working, I notice my notes on exchange don't show up as memos in evolution and instead appear as a folder in the Mail view.  Is this the correct behaviour or should I raise it as a bug or feature request?
Comment 9 Milan Crha 2012-06-11 10:30:18 UTC
(In reply to comment #8)
> All working now. Thanks very much! 

Nice, I thank you for confirmation.

> A quick question - now it's working, I notice my notes on exchange don't show
> up as memos in evolution and instead appear as a folder in the Mail view.  Is
> this the correct behaviour or should I raise it as a bug or feature request?

It's the current behaviour. I wouldn't call it correct behaviour for sure. Please file it as a new enhancement request, thus it's not forgotten (I didn't find any such request in filled ews bugs).
Comment 10 Milan Crha 2012-06-11 12:28:10 UTC
Created commit 8b744e5 in ews gnome-3-4 (3.4.3+)
Comment 11 Milan Crha 2012-06-11 12:31:23 UTC
Matthew, could you port the patch to git master of ews, please? I tried to, but I do not follow changes there at all. Please note that I added custom property "ews-auth-type" into ESource, based on the Camel's chosen auth type, but I'm rather lost in the module-ews-backend.c, where I suppose this should be gathered with some magic too. otherwise the patch is pretty straightforward, I believe.
Comment 12 Matthew Barnes 2012-06-11 12:58:24 UTC
EWS uses CamelEwsSettings throughout now, and CamelEwsSettings also implements the CamelNetworkSettings interface which has the auth type.  So it's probably less complex than you think: there's no need for a new ESource property, just use Camel's chosen auth type directly.

In any case, I'll see what I can do.
Comment 13 Milan Crha 2012-07-03 07:17:55 UTC
ping Matthew.
Comment 14 Matthew Barnes 2012-07-03 19:56:14 UTC
I'll get to this.  Kolab is the higher priority right now since Christian is waiting on me.
Comment 15 cowardlysnake 2012-07-07 13:17:24 UTC
I just tried a fresh install of Fedora 17 and this is broken again.  Basic authentication is used for the autodiscover "Fetch URL" part of the account creation but it reverts to NTLM once the account is created.

I've tried disabling and enabling the account and also restarting evolution but it always uses NTLM.  I verified this in the EWS_DEBUG=2 output.

Interestingly, the autodiscover is working better now. It gets the address correct for the OAB URL but still changes the Host URL to an internal address.

evolution,evolution-ews,evolution-data-server are all version 3.4.3-1.fc17 (64bit)
Comment 16 Milan Crha 2012-07-09 08:11:23 UTC
Strange, it works fine for me with 3.4.3 packages, I can change Auth type and it is stored and used as expected. When I open Edit->Preferences->Mail Accounts-><ews account>->Edit, then I see there stored the auth type as it was. My libsoup is libsoup-2.38.1-1.fc17.x86_64 and glib-networking-2.32.3-1.fc17.x86_64.
Comment 17 cowardlysnake 2012-07-11 19:37:50 UTC
I've got it working again.  It appears a reboot is required once the account is configured for it work properly.
Comment 18 Milan Crha 2012-07-13 07:43:48 UTC
Slightly modified patch committed to ews master as 1020b32 (3.5.4+)