| Summary: | Akonadi EWS failed to authenticate with Exchange Server | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] Akonadi | Reporter: | Olivier <olivier.dugeon> |
| Component: | EWS Resource | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | CONFIRMED --- | ||
| Severity: | major | CC: | anders, denysmb112007, dion, dominik.schlack, francisco, frank-fischer, hujq, igitur, k, krissn, maniac, Martin, me+kde, m_louis30, nick.berg3, paolo.pedroni, petersaints, postix, vmatare+kdebug, yaohan.chen |
| Priority: | NOR | ||
| Version: | 5.7.2 | ||
| Target Milestone: | --- | ||
| Platform: | Kubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Akonadi log when creating an EWS account in kmail | ||
|
Description
Olivier
2018-02-20 17:58:11 UTC
I can confirm this behavior, though i'm not sure the cause is the same. I found that the Password field is always empty on editing an account. Also, in kwalletmanager the akonadi folder is created, but no entrys are created. I'm not sure wether it should or not. Just something i noticed. Also, i can confirm my account working on the same mashine with evolution-ews Also, this might be a duplicate of 390260 (In reply to dominik.schlack from comment #2) > Also, this might be a duplicate of 390260 wrong one. It's 389369 I have the same issue with kdepim version 17.12.3. The password is stored in the password dialog, and clicking on "Try connect" works - the status on the tab "Status" changes to OK then and presents the Exchange version number (in my case, 14.3.361.1 Exchange 2010 SP3). But the "Subscription" tab shows "Failed to retrieve folder list", and when I close the dialog with OK, the account itself shows "Unable to connect to Exchange server". If you need more info to diagnose this problem, please let me know. Another, maybe unrelated issue - in the Evolution EWS plugin, I can login to the EWS account using my email address and password. In the akonadi plugin, I have to use a strange user name that took me a while to find in the interface of the Exchange webmail. (In reply to Olivier from comment #0) > Once configured Akonadi EWS plugin, clikc on "Test Connection work", but > click on "OK" failed and plugin remains not connected. > > Once activate kio_http debug, it seems that the NTLM handshake is correctly > executed when testing the connection. Akonadi EWS try without any auth, got > a 401, then try with simple NTLM v1, got 401 again, and finally try with > NTLMv2 and got a 200 OK. When clicking on "OK", Akonadi EWS just try NTLMv1 > and newer try NTLMv2. > > It seems that this bugs is related to old NTLM problem in kio_http patched > by the author of akonadi_ews plugin. > > Note that same credential with Exchange or Thunderbird work fine and that > using a kerberos ticket allows authentication. I am on the latest Kubuntu (actually, still development version for the next two days) with akonadi version 17.12.3 (it claims akonadi_ews is 5.7.3) and see the same problem. The password never shows up in kwallet and "Failed to retrieve folder list." It works fine on my work computer with Kubuntu 17.04.3 and akonadi_ews 0.8.1-1.1-1. (In reply to Anders Bolager from comment #5) > I am on the latest Kubuntu (actually, still development version for the next > two days) with akonadi version 17.12.3 (it claims akonadi_ews is 5.7.3) and > see the same problem. The password never shows up in kwallet entry for and "Failed to > retrieve folder list." It works fine on my work computer with Kubuntu > 17.04.3 and akonadi_ews 0.8.1-1.1-1. I also get this error message in akonadiconsole: AgentBase(akonadi_ews_resource_2): Root folder id not known. Anders, the behaviour you mentioned with the password not being stored sounds more like bug 393002, not this bug (where the password is stored but EWS fails to connect). Christian, that may well be true. I've added some information to that bug. After manually inserting the password into kwallet (and seeing it showing up in the configuration GUI) I still cannot fetch the folder list. *** Bug 390139 has been marked as a duplicate of this bug. *** *** Bug 390799 has been marked as a duplicate of this bug. *** Git commit a20701f5837e067496ef91954940c49eb9e15beb by Stefan Brüns.
Committed on 03/05/2018 at 22:38.
Pushed by bruns into branch 'master'.
Always add domain delimiter if "Domain" checkbox is selected
Summary:
EwsConfigDialog::fullUsername() always adds the domain delimiter when
the "Domain" checkbox is set, even if the actual domain name is empty,
while the login procedure in EwsResource::passwordRequestFinished(...)
only adds a domain delimiter if the domain is non-empty. Make sure
login in the config dialog and during normal operation is equivalent.
Not sending an (empty) domain causes login failures for some servers,
while sending it seems to be unproblematic, and can be forced off by
unselecting the checkbox.
This fixes a regression caused by commit
7c74258355cd ("EWS: Refactor server connection and password retrieval"),
which changed the check for sending the domain from mSettings->hasDomain()
to mSettings->domain().isEmpty().
Related: bug 388496
Test Plan:
Check the login from the config-dialog, once //with//, once //without//
checking "Domain"
Try to sync the resource
Reviewers: dvratil, nowicki
Reviewed By: dvratil
Subscribers: #kde_pim
Tags: #kde_pim
Differential Revision: https://phabricator.kde.org/D12474
M +1 -1 resources/ews/ewsresource.cpp
https://commits.kde.org/kdepim-runtime/a20701f5837e067496ef91954940c49eb9e15beb
Git commit 86302684a48fb4340facd5f773ab14556bc82219 by Stefan Brüns.
Committed on 03/05/2018 at 22:38.
Pushed by bruns into branch 'master'.
Always add domain delimiter if "Domain" checkbox is selected
Summary:
EwsConfigDialog::fullUsername() always adds the domain delimiter when
the "Domain" checkbox is set, even if the actual domain name is empty,
while the login procedure in EwsResource::passwordRequestFinished(...)
only adds a domain delimiter if the domain is non-empty. Make sure
login in the config dialog and during normal operation is equivalent.
Not sending an (empty) domain causes login failures for some servers,
while sending it seems to be unproblematic, and can be forced off by
unselecting the checkbox.
This fixes a regression caused by commit
7c74258355cd ("EWS: Refactor server connection and password retrieval"),
which changed the check for sending the domain from mSettings->hasDomain()
to mSettings->domain().isEmpty().
Related: bug 388496
Test Plan:
Check the login from the config-dialog, once //with//, once //without//
checking "Domain"
Try to sync the resource
Reviewers: dvratil, nowicki
Reviewed By: dvratil
Subscribers: #kde_pim
Tags: #kde_pim
Differential Revision: https://phabricator.kde.org/D12474
https://commits.kde.org/kdepim-runtime/86302684a48fb4340facd5f773ab14556bc82219
Stefan, thanks! I've applied that patch to kdepim-runtime 17.12.3 and it fixed my problem. I can confirm that it seems to work here too, though I did have to change version numbers from 5.8.* to 5.7.3 in some of the cmake files to get it to compile on my Ubuntu 18.04 installation. KMail also crashed a few times on a newly downloaded Office365 mail setup. I will need to move the compiled files to my work computer to really test it (still running Ubuntu 17.10) since I just set it up at home to test, but thanks a lot for your work Stefan Brüns! Crashes seems do to a strange graphics card problem. [699755.352402] nouveau 0000:02:00.0: kmail[953]: Unknown handle 0x00000034 [699755.352413] nouveau 0000:02:00.0: kmail[953]: validate_init [699755.352416] nouveau 0000:02:00.0: kmail[953]: validate: -2 [700326.206896] nouveau 0000:02:00.0: kmail[10680]: Unknown handle 0x00000035 [700326.206907] nouveau 0000:02:00.0: kmail[10680]: validate_init [700326.206909] nouveau 0000:02:00.0: kmail[10680]: validate: -2 So not related to this patch. What is the best way to apply this patch to fix this issue? I am on Kubuntu 18.04. Hello. Olivier, thanks for the bug report and all the others for their findings about it. As Stefan committed what appears to be a fix to me quite some time ago, is the issue fixed meanwhile? Hello Martin I recently upgrade to latest Neon packages: 18.12.2, so kdepim 5.10.2, and performed a new test. Unfortunately, it is always the same. Only kerberos authentication works. I always got the same error 401 in the console when attempting to login with my login/password. Perhaps it is due to our version of Exchange Server. Olivier, thank you for confirming with newest version. What version does your Exchange server have? Can anyone else confirm it? I am a bit puzzled about the bug report after reading through it again. I have the feeling that it is about several different issues. So or so would be helpful to have some logging / console output, when the issue happens. Martin, I activate debug level for ews and http (through kdebugsettings application) and made another attempt. Here it is what I got when I run akonadictl start: org.kde.pim.ews: Setting up authentication org.kde.pim.ews: Using password-based authentication Empty filename passed to function org.kde.pim.ews: Initializing authentication org.kde.pim.ews: requestPassword: start org.kde.pim.ews: satisfyPasswordReadRequest: got password org.kde.pim.akonadi_indexer_agent: Failed to fetch items: "Collection does not exist" org.kde.pim.akonadi_indexer_agent: Indexing failed: "" org.kde.pim.ews.client.proto: "<?xml version=\"1.0\"?><soap:Envelope xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\"><soap:Header><t:RequestServerVersion Version=\"Exchange2007_SP1\"/></soap:Header><soap:Body><m:GetFolder><m:FolderShape><t:BaseShape>IdOnly</t:BaseShape><t:AdditionalProperties><t:FieldURI FieldURI=\"folder:DisplayName\"/><t:ExtendedFieldURI PropertySetId=\"9bf757ae-69b5-4d8a-bf1d-2dd0c0871a28\" PropertyName=\"GlobalTags\" PropertyType=\"StringArray\"/><t:ExtendedFieldURI PropertySetId=\"9bf757ae-69b5-4d8a-bf1d-2dd0c0871a28\" PropertyName=\"GlobalTagsVersion\" PropertyType=\"Integer\"/></t:AdditionalProperties></m:FolderShape><m:FolderIds><t:DistinguishedFolderId Id=\"msgfolderroot\"/><t:DistinguishedFolderId Id=\"inbox\"/></m:FolderIds></m:GetFolder></soap:Body></soap:Envelope>\n" org.kde.pim.ews.client.request: Starting GetFolder request ((EwsId(Distinguished: msgfolderroot), EwsId(Distinguished: inbox))) org.kde.pim.akonadi_indexer_agent: Failed to fetch items: "Collection does not exist" org.kde.pim.akonadi_indexer_agent: Indexing failed: "" org.kde.pim.akonadi_indexer_agent: Failed to fetch items: "Collection does not exist" org.kde.pim.akonadi_indexer_agent: Indexing failed: "" org.kde.pim.ews.client.proto: data KIO::TransferJob(0x55587302c590) "" org.kde.pim.ews.client.proto: response dumped to "/tmp/akonadi-ews-iTJfTtK/ews_xmldump_LBepRPi.xml" org.kde.pim.ews.client: Failed to process EWS request - HTTP code 401 ERROR "Failed to process EWS request - HTTP code 401" org.kde.pim.ews: requestAuthFailed - going offline Note that the response dumped to the file "/tmp/akonadi-ews-iTJfTtK/ews_xmldump_LBepRPi.xml" is empty. You could also note that the Exchange server is version 2007_SP1, perhaps too old, but I have no possibility to change this. Also note that, Kerberos authentication is no longer working now. To perform the test, I start by removing all EWS configuration and then recreate new one. So, now I have no solution to access to my calendar and mail with akonadi. Encountered this bug while setting up exchange connection. Here are debug logs from kio_http and pim.ews with username, domain, cookies and ntlm challenge/response data redacted: org.kde.pim.ews: Setting up authentication org.kde.pim.ews: Using password-based authentication org.kde.pim.ews: Initializing authentication org.kde.pim.ews: requestPassword: start org.kde.pim.ews: requestPassword: password already set org.kde.pim.ews.client.proto: "<?xml version=\"1.0\"?><soap:Envelope xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\"><soap:Header><t:RequestServerVersion Version=\"Exchange2007_SP1\"/></soap:Header><soap:Body><m:GetFolder><m:FolderShape><t:BaseShape>IdOnly</t:BaseShape><t:AdditionalProperties><t:FieldURI FieldURI=\"folder:DisplayName\"/><t:ExtendedFieldURI PropertySetId=\"9bf757ae-69b5-4d8a-bf1d-2dd0c0871a28\" PropertyName=\"GlobalTags\" PropertyType=\"StringArray\"/><t:ExtendedFieldURI PropertySetId=\"9bf757ae-69b5-4d8a-bf1d-2dd0c0871a28\" PropertyName=\"GlobalTagsVersion\" PropertyType=\"Integer\"/></t:AdditionalProperties></m:FolderShape><m:FolderIds><t:DistinguishedFolderId Id=\"msgfolderroot\"/><t:DistinguishedFolderId Id=\"inbox\"/></m:FolderIds></m:GetFolder></soap:Body></soap:Envelope>\n" org.kde.pim.ews.client.request: Starting GetFolder request ((EwsId(Distinguished: msgfolderroot), EwsId(Distinguished: inbox))) kf5.kio.kio_http: kf5.kio.kio_http: QUrl("https://DOMAIN_NAME%5CUSERNAME@EXCHANGE_ADDR/EWS/Exchange.asmx") kf5.kio.kio_http: QUrl("https://DOMAIN_NAME%5CUSERNAME@EXCHANGE_ADDR/EWS/Exchange.asmx") kf5.kio.kio_http: Window Id = "" kf5.kio.kio_http: ssl_was_in_use = "" kf5.kio.kio_http: kf5.kio.kio_http: kf5.kio.kio_http: kf5.kio.kio_http: kf5.kio.kio_http: kf5.kio.kio_http: Proxy URLs: () kf5.kio.kio_http: TCP_NODELAY: QVariant(int, 0) kf5.kio.kio_http: ============ Sending Header: kf5.kio.kio_http: "POST /EWS/Exchange.asmx HTTP/1.1" kf5.kio.kio_http: "Host: EXCHANGE_ADDR" kf5.kio.kio_http: "Connection: keep-alive" kf5.kio.kio_http: "User-Agent: Mozilla/5.0 (X11; Linux x86_64; English) KHTML/5.58.0 (like Gecko) Konqueror/5 KIO/5.58" kf5.kio.kio_http: "Pragma: no-cache" kf5.kio.kio_http: "Cache-control: no-cache" kf5.kio.kio_http: "Accept: text/html, text/*;q=0.9, image/jpeg;q=0.9, image/png;q=0.9, image/*;q=0.9, */*;q=0.8" kf5.kio.kio_http: "Accept-Encoding: gzip, deflate, x-gzip, x-deflate" kf5.kio.kio_http: "Accept-Charset: utf-8,*;q=0.5" kf5.kio.kio_http: "Accept-Language: en-US,en;q=0.9" kf5.kio.kio_http: "Cookie: X-BackEndCookie=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx; exchangecookie=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" kf5.kio.kio_http: "Content-Type: text/xml" kf5.kio.kio_http: sent it! kf5.kio.kio_http: sending data (size= 898 ) kf5.kio.kio_http: "Content-Length: 898" kf5.kio.kio_http: kf5.kio.kio_http: ============ Received Status Response: kf5.kio.kio_http: "HTTP/1.1 401 Unauthorized" kf5.kio.kio_http: QUrl("https://DOMAIN_NAME%5CUSERNAME@EXCHANGE_ADDR/EWS/Exchange.asmx") response code: 401 previous response code: 0 kf5.kio.kio_http: wasAuthError= false isAuthError= true sameAuthError= false kf5.kio.kio_http: -- full response: "HTTP/1.1 401 Unauthorized\r\nrequest-id: 5d252ae0-ddd8-4e94-ab13-aa75e76fafa0\r\nWWW-Authenticate: Negotiate\r\nWWW-Authenticate: NTLM\r\nX-FEServer: E24\r\nDate: Tue, 11 Jun 2019 19:16:16 GMT\r\nContent-Length: 0\r\nX-Content-Type-Options: nosniff\r\nStrict-Transport-Security: max-age=31536000; includeSubDomains\r\nContent-Security-Policy: script-src 'self' 'unsafe-inline' 'unsafe-eval'\r\nX-XSS-Protection: 1; mode=block\r\nReferrer-Policy: no-referrer\r\nAccess-Control-Allow-Origin: null\r\nCache-Control: private, no-cache, no-store, must-revalidate, max-age=0\r\nExpires: 0" kf5.kio.kio_http: Trying authentication scheme: "Negotiate" kf5.kio.kio_http.auth: gss_init_sec_context failed: "Unspecified GSS failure. Minor code may provide more information SPNEGO cannot find mechanisms to negotiate " kf5.kio.kio_http: isError= true needCredentials= false forceKeepAlive= false forceDisconnect= false kf5.kio.kio_http: Blacklisting auth "Negotiate" kf5.kio.kio_http: Trying authentication scheme: "NTLM" kf5.kio.kio_http: isError= false needCredentials= false forceKeepAlive= false forceDisconnect= false kf5.kio.kio_http: "0" bytes left. kf5.kio.kio_http: bytesReceived: 0 m_iSize: 0 Chunked: false BytesLeft: 0 kf5.kio.kio_http: EOD received! Left = "0" kf5.kio.kio_http: kf5.kio.kio_http: kf5.kio.kio_http: kf5.kio.kio_http: kf5.kio.kio_http: ============ Sending Header: kf5.kio.kio_http: "POST /EWS/Exchange.asmx HTTP/1.1" kf5.kio.kio_http: "Host: EXCHANGE_ADDR" kf5.kio.kio_http: "Connection: keep-alive" kf5.kio.kio_http: "User-Agent: Mozilla/5.0 (X11; Linux x86_64; English) KHTML/5.58.0 (like Gecko) Konqueror/5 KIO/5.58" kf5.kio.kio_http: "Pragma: no-cache" kf5.kio.kio_http: "Cache-control: no-cache" kf5.kio.kio_http: "Accept: text/html, text/*;q=0.9, image/jpeg;q=0.9, image/png;q=0.9, image/*;q=0.9, */*;q=0.8" kf5.kio.kio_http: "Accept-Encoding: gzip, deflate, x-gzip, x-deflate" kf5.kio.kio_http: "Accept-Charset: utf-8,*;q=0.5" kf5.kio.kio_http: "Accept-Language: en-US,en;q=0.9" kf5.kio.kio_http: "Cookie: X-BackEndCookie=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx; exchangecookie=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" kf5.kio.kio_http: "Content-Type: text/xml" kf5.kio.kio_http: "Authorization: NTLM XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" kf5.kio.kio_http: sent it! kf5.kio.kio_http: kf5.kio.kio_http: ============ Received Status Response: kf5.kio.kio_http: "HTTP/1.1 401 Unauthorized" kf5.kio.kio_http: QUrl("https://DOMAIN_NAME%5CUSERNAME@EXCHANGE_ADDR/EWS/Exchange.asmx") response code: 401 previous response code: 401 kf5.kio.kio_http: wasAuthError= true isAuthError= true sameAuthError= true kf5.kio.kio_http: -- full response: "HTTP/1.1 401 Unauthorized\r\nrequest-id: 185fe6d4-09ef-4c75-bca7-245401827487\r\nWWW-Authenticate: NTLM XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\r\nWWW-Authenticate: Negotiate\r\nX-FEServer: E24\r\nDate: Tue, 11 Jun 2019 19:16:16 GMT\r\nContent-Length: 0\r\nX-Content-Type-Options: nosniff\r\nStrict-Transport-Security: max-age=31536000; includeSubDomains\r\nContent-Security-Policy: script-src 'self' 'unsafe-inline' 'unsafe-eval'\r\nX-XSS-Protection: 1; mode=block\r\nReferrer-Policy: no-referrer\r\nAccess-Control-Allow-Origin: null\r\nCache-Control: private, no-cache, no-store, must-revalidate, max-age=0\r\nExpires: 0" kf5.kio.kio_http: Trying authentication scheme: "NTLM" kf5.kio.kio_http: looks like the user canceled the authentication dialog kf5.kio.kio_http: Previous Response: 401 kf5.kio.kio_http: Current Response: 401 kf5.kio.kio_http: "0" bytes left. kf5.kio.kio_http: bytesReceived: 0 m_iSize: 0 Chunked: false BytesLeft: 0 kf5.kio.kio_http: EOD received! Left = "0" kf5.kio.kio_http: kf5.kio.kio_http: keepAlive = true kf5.kio.kio_http: kf5.kio.kio_http: keep alive ( 60 ) org.kde.pim.ews.client.proto: data KIO::TransferJob(0x55f70b415fa0) "" org.kde.pim.ews.client.proto: response dumped to "/tmp/akonadi-ews-ndWdUle/ews_xmldump_QDtcEwr.xml" org.kde.pim.ews.client: Failed to process EWS request - HTTP code 401 ERROR "Failed to process EWS request - HTTP code 401" org.kde.pim.ews: requestAuthFailed - going offline kf5.kio.kio_http: kf5.kio.kio_http: kf5.kio.kio_http: kf5.kio.kio_http: kf5.kio.kio_http: keepAlive = false kf5.kio.kio_http: kf5.kio.kio_http: I didnt set up kerberos at all, I have domain, username and email set in ews resource rc, querying with dbus shows hasDomain=true and enableNTLMv2=true. I tried to find source of this bug myself with no results, this whole thing is quite complex. What bothers me is 'looks like the user canceled the authentication dialog' line, like kio_http tries to fetch data again after getting NTLM challenge, but abandons attempt immediately. Versions installed: kde-frameworks/kio: 5.58.0, kde-apps/kdepim-runtime: 19.04.2, akonadi-ews-resource's about dialog shows version: 5.11.2. Hope this helps. Git commit 7afd99abbfa141f6e6dfbe69b01827af8f16ba27 by Igor Poboiko. Committed on 20/03/2020 at 16:10. Pushed by poboiko into branch 'master'. [resources/ews] Save password to wallet Summary: Seems like the password entered via the UI actually never gets saved anywhere. Just do it explicitly. Related: bug 393002, bug 402780, bug 414789 Test Plan: 1) Try to setup EWS account using autodiscovery, using Username/Password auth 2) Set Username, Password, hit "Try connect" -> it works fine 3) Hit "OK" -> observe "Authentication failure" resource error 4) Browse `akonadi-ews` via `KWalletManager` -> it's empty 5) Apply the patch, repeat 1-4 - authentication succeeds, password entry inside wallet appears Reviewers: dvratil, nowicki Reviewed By: dvratil Subscribers: kde-pim Tags: #kde_pim Differential Revision: https://phabricator.kde.org/D27813 M +1 -0 resources/ews/ewsconfigdialog.cpp https://commits.kde.org/kdepim-runtime/7afd99abbfa141f6e6dfbe69b01827af8f16ba27 YES, the patch from 7afd99ab fixes the problem for me. I now can finally access my calendar. Thank you very much Igor! The fix is still no part of akonadi 20.04, is it? Will it be released as part of 20.08? In the meantime, I found this workaround: https://github.com/KrissN/akonadi-ews/issues/48#issuecomment-370542561 Trying to setup a new ews account, authentication is successful when testing connection but the "OK" button remains greyed out. As the configuration has not been saved to this point, the workaround has been not useful, kdepim-runtime 20.04 QWebEngineUrlScheme::registerScheme() before installing the custom scheme handler. org.kde.pim.ews.client: Starting OAuth2 authentication org.kde.pim.ews.client: Launching browser for authentication org.kde.pim.ews.client: PKeyAuth certificates not found org.kde.pim.ews.client: Authentication succeeded (In reply to Francisco Isgleas from comment #25) > kdepim-runtime 20.04 > 20.04 doesn't contain Igor's commit: % git tag --contains 7afd99ab v20.07.80 v20.07.90 v20.08.0 v20.08.1 v20.08.2 Created attachment 147659 [details]
Akonadi log when creating an EWS account in kmail
I'm still having this problem with kdepim 22.03.80. (After completing OAuth in the browser popup, the "OK" button in the dialog remains disabled.) Attached akonadi log of my attempt to create EWS account. I can confirm that, after recent updates, the EWS service stopped to work. |