Thunderbird 52 / Lightning 5.4 support

[bren-m]

Hi All,

Thunderbird auto-upgraded to version 52 today and as a result Lightning upgraded to 5.4.

I can no longer connect to my Exchange server using the Exchange Calendar add-on versions 3.8.0 or 3.9.0.

Is Thunderbird 52 / Lightning 5.4 supported by this add-on or is a new version going to be released that provides support.

Thanks, Brendon

[jpstotz]

I just made a small test in TB 52 that disproved my assumption that something is wrong in general with the NTLM authentication. In the JS-environment of the debugging tools I wrote a small code snippet that replays the request I have seen on network level using a XMLHttpRequest. After adding the necessary headers (except for authentication) and the SOAP body Thunderbird automatically used NTLM authentication.

Hence the requirement for a successful authentication seems to be present - the problem may be a misconfiguration or the special way the request is executed.

BTW: Is developing a Thunderbird add-on really that painful? Using the debugging tools one can view and debug the JavaScript code, but if you want to change a single bit you have to edit the JS file and restart TB!?

[rkent]

Here's my analysis of the issues.

In Mozilla bug 1221320, changes were done to XMLHttpRequest so that the authPrompt dialog only appears if neither username nor password is set in the request URL. So you only asyncPromptAuth called when both are blank. But Exchange calendar sets a username on the first authentication attempt (supporting Basic and Kerberos), expecting a callback to asyncPromptAuth if that fails, which it does for NTLM.

But further changes to authentication are all controlled through these asyncPromptAuth calls which never occur, hence the failure.

I can get NTLM authentication to work with Exchange Calendar and TB 52.0 by doing retries on the load callback from the http 401, but other things then break (like Basic), and in any case autodiscover fails.

In ExQuilla, I do not have these problems, and NTLM and Basic both work fine with Thunderbird 52. I think this is because I do not rely on these asyncPromptAuth callbacks to control things. Unfortunately NTLM has always involved a bit of black magic in Mozilla code, as its connection-based authentication is strange.

Unfortunately I do not have time to work on this again for at least another week, and I don't really understand the particular type of authentication black magic used by Exchange Calendar in the first place. I'm hoping that one of the talented developers looking at this can figure out what the right changes are to Exchange Calendar, understanding this issue as the root cause.

[fthommen]

Maybe someone with more technical knowhow on Thunderbird software development could also comment on https://bugzilla.mozilla.org/show_bug.cgi?id=1359629?

[rkent]

In response to fthommen:

Adding EWS as a "supported" protocol to core Thunderbird does not magically make the resources appear to maintain it. This particular addon, Exchange Calendar, is a really good example of the problems. The work required is substantial, a free-as-in-beer developer can enjoy working on it for awhile, but then there is the inevitable burnout followed by periods of poor support, which we seem to be in the third phase of now. Personally, I believe that something mission-critical like Thunderbird (and critical addons such as this one) deserve better than that if people are going to rely on them to get real work done.

But this gets at the core of what people mean by "open source" and "free software". There is always that hope that there are lots of potentially motivated volunteers that could be attracted, if somehow we just do things better.

Personally I don't believe in that, but I am in a minority - and I get plenty of flak for charging for ExQuilla. (Note I am the ExQuilla author as well as a member of the Thunderbird Council). The solution that I think makes sense is something like a non-profit user coop, where there would be enough benefits to the users to pay for membership, the code could continue open source, but somebody would be paid to keep the lights on. We're collecting substantial donations now, and that is helping alot, but not enough to imagine that EWS could be added to core Calendar and supported.

Looking ahead a few years, I tend to agree with probably most of you that EWS support should be a critical part of the maintained core. I've got a group of volunteers I am working with (http://caspia.org) that will work on the rewrite of both Contacts and Calendar as a part of a next-generation Thunderbird project, and I intend to make EWS core to that. But that does not solve the long-term financial issues.

[fthommen]

@rkent : I fully agree and I also want to add, that I have no problem paying for software I critically rely on. This plugin (even TB itself) would be an example of software that I would be willing to pay for, as I don't want to live w/o them any more :-)

[jpstotz]

@rkent Thanks for outlining the real problem. As a first work-around I commented out lines 275 to 290 in components/ecExchangeRequest.js and replaced it with the following line:

this.xmlReq.open("POST", this.currentUrl, true);

I also added the DNS name of the Exchange server in the configuration property network.automatic-ntlm-auth.trusted-uris. Afterwards my calendar was accessible again, however I assume this work-around will only work for environments where the logged-on user account is an Active Directory account and this account is also used for the Exchange mailbox.

[kragil]

TB Update fixed it for me.

[fthommen]

@kragil: Update to what? 52.1.0? Doesn't fix it for me (Lightning 5.4.1, Mac OS X 10.9.5)

[tmeader]

@jpstotz Thanks for the notes. Sadly that didn't seem to work for me on 3.9.0 with TB 52.1.0. I'm definitely on an AD user account that's the same for Exchange. I've tried going through the autodiscover method (after also whitelisting the autodiscover URI, both http and https) and explicitly entering the server URL. Neither work. Still comes back with Unauthorized -19. Oh well.

[jpstotz]

@tmeader Have you made the modification I proposed? You need both, the modification and the network.automatic-ntlm-auth.trusted-uris setting.

[tmeader]

@jpstotz Correct. Everything between lines 275-289 (290 is blank) is commented out. The line you cited (on line 274) was uncommented.

Still not working.

[lemmy04]

"me too", TB 52.1.0 on windows, exchangecalendar 3.9.0, unmodified so far.

[dom11990]

Just wanted to let people know that I found an alternative you may use while this issue is being worked out. I currently use a combination of DavMail and TB 52 for my exchange calendar. Seems to work correctly.

I'm on arch so I installed davmail from the AUR. Your respective distro probably has compiled binaries somewhere. After installation, run DavMail and go to "Settings" on the yellow system tray icon. There you need to fix the link. ex: https://mail.company.de/owa. I only left CalDav and LDAP checked because I already have my regular mail going over IMAP and SMTP.

Then follow the instructions here to pull the calendar into TB. They don't match perfectly but I was able to get it working in about 30s so I don't imagine it will be too much trouble for any of the users here..

http://davmail.sourceforge.net/thunderbirdcalendarsetup.html

[tilsche]

DavMail does not seem to be a viable alternative to me. I setup the latest release as a standalone server together with Thunderbird 52.0 (archlinux) and have seen so far:

• "Unnamed" recurring events
• "Item Modification Conflict" "The item being edited in the dialog has been modified since it was opened." whenever I create a new event
• Constant yellow warning "The calendar ... is momentarily not available"
• Two undistinguishable "Calendar" entries in DAVdroid

[troyengel]

This is way off topic, but since y'all brought it up - as an Arch user in business, having my Exchange calendar functional is vastly more important than upgrading Thunderbird for whatever new things they decided to do which broke this extension. Go here:

• https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/thunderbird&id=c4f1edde3a18fc950c7fe2aa620bb2319ccd9e1c

...bump the PKGBUILD release to '2', run makepkg on it and build a new copy of Thunderbird 45.8.0-2 against the recent icu/hunspell upgrades and you'll be back in shape to install it. Don't forget to blacklist the thunderbird upgrade in /etc/pacman.conf so it won't try to re-upgrade to 52.x again. It's a solution if you're in a bind like me and just need things to work. If you already upgraded your TB, remember to downgrade your Lightning extension to 4.7.8 again.

I greatly appreciate the work this team is doing to sort out whatever has broken, please don't misunderstand. Just presenting an interim workaround for Arch users while this issue is sorted out.

[jpstotz]

@troyengel If you continue using the old version you should pray that no-one tries to exploit the vulnerabilities of this old version - and there are plenty of them (just the one for fixed in 52.1): https://www.mozilla.org/en-US/security/advisories/mfsa2017-13/

[troyengel]

@jpstotz this is true of any software. Sometimes one has to make calculated decisions of risk to achieve a desired goal; if the solution does not work for you, walk away and use your own.

[meonwax]

@troyengel I created an AUR package for this: https://aur.archlinux.org/packages/thunderbird-45-gtk2/

[midluk]

I had the same problem previously, but it now suddenly works again. I don't think anything changed on my side. Perhaps there was some server-side change.

[gomezalberto]

Same here, suddenly works...!

On Fri, May 5, 2017 at 11:42 AM, Lukas Middendorf notifications@github.com wrote:

I had the same problem previously, but it now suddenly works again. I don't think anything changed on my side. Perhaps there was some server-side change.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Ericsson/exchangecalendar/issues/580#issuecomment-299434398, or mute the thread https://github.com/notifications/unsubscribe-auth/ABm1YiaanBfLy2pE7mkDYuLAOcn9sar4ks5r2v0tgaJpZM4Mz4q_ .

[jretxaniz]

Unfortunately with my configuration: TB 52.1.0; EWS Provider 3.9.0.x; Lightning 5.4.1 I have the same issue. 401 ERROR

[stenoo83]

is there a way to store manually a password bypassing prompt message?

[Trim]

Hello, Just a side a note about my progress looking on this error: it seems that the code from components/ecExchangeRequest.js is not the issue.

Issue seems between this code and the callback to the interfaces/exchangeAuthPrompt2/mivExchangeAuthprompt2.js code.

Indeed, in my setup with TB 45 and EC 3.9, my log contains after the XLM HTTP Request was send():

1st-setup:2017-4-5 22:22:27.131:mivExchangeAuthPrompt2: asyncPromptAuth: level=2 (_asyncPromptAuth in mivExchangeAuthPrompt2.js:448)
1st-setup:2017-4-5 22:22:27.131:mivExchangeAuthPrompt2: asyncPromptAuth: channel.status=0 (_asyncPromptAuth in mivExchangeAuthPrompt2.js:449)
1st-setup:2017-4-5 22:22:27.132:mivExchangeAuthPrompt2: asyncPromptAuth: channel.responseStatus=401 (_asyncPromptAuth in mivExchangeAuthPrompt2.js:451)
1st-setup:2017-4-5 22:22:27.133:mivExchangeAuthPrompt2: asyncPromptAuth: channel.responseStatusText=Anonymous Request Disallowed (_asyncPromptAuth in mivExchangeAuthPrompt2.js:452)
1st-setup:2017-4-5 22:22:27.134:mivExchangeAuthPrompt2: asyncPromptAuth: authInfo.authenticationScheme=ntlm (_asyncPromptAuth in mivExchangeAuthPrompt2.js:454)
1st-setup:2017-4-5 22:22:27.135:mivExchangeAuthPrompt2: asyncPromptAuth: authInfo.realm= (_asyncPromptAuth in mivExchangeAuthPrompt2.js:455)
1st-setup:2017-4-5 22:22:27.135:mivExchangeAuthPrompt2: asyncPromptAuth: authInfo.username= (_asyncPromptAuth in mivExchangeAuthPrompt2.js:456)
1st-setup:2017-4-5 22:22:27.136:mivExchangeAuthPrompt2: asyncPromptAuth: authInfo.password=************ (_asyncPromptAuth in mivExchangeAuthPrompt2.js:462)
1st-setup:2017-4-5 22:22:27.137:mivExchangeAuthPrompt2: asyncPromptAuth: authInfo.domain= (_asyncPromptAuth in mivExchangeAuthPrompt2.js:464)
1st-setup:2017-4-5 22:22:27.138:mivExchangeAuthPrompt2: asyncPromptAuth: aChannel.URL=https://myanonymezed.provider/ews/exchange.asmx, username=email@example.org, password=******** (_asyncPromptAuth in mivExchangeAuthPrompt2.js:471)
1st-setup:2017-4-5 22:22:27.139:mivExchangeAuthPrompt2: asyncPromptAuth: authInfo.flags & AUTH_HOST (_asyncPromptAuth in mivExchangeAuthPrompt2.js:485)
1st-setup:2017-4-5 22:22:27.140:mivExchangeAuthPrompt2: asyncPromptAuth: authInfo.flags & NEED_DOMAIN (_asyncPromptAuth in mivExchangeAuthPrompt2.js:487)
1st-setup:2017-4-5 22:22:27.140:mivExchangeAuthPrompt2: asyncPromptAuth: NO Authorization in request header!? (_asyncPromptAuth in mivExchangeAuthPrompt2.js:505)
1st-setup:2017-4-5 22:22:27.141:mivExchangeAuthPrompt2: asyncPromptAuth: Added request to queue[https://myanonymezed.provider/ews/exchange.asmx]. There are now '1' request in queue. (_asyncPromptAuth in mivExchangeAuthPrompt2.js:516)
1st-setup:2017-4-5 22:22:27.142:mivExchangeAuthPrompt2: asyncPromptAuthNotifyCallback: Removed request from queue[https://myanonymezed.provider/ews/exchange.asmx]. There are now '0' requests in queue left. (_asyncPromptAuthNotifyCallback in mivExchangeAuthPrompt2.js:282)
1st-setup:2017-4-5 22:22:27.143:mivExchangeAuthPrompt2: asyncPromptAuthNotifyCallback: Trying to detect username. (_asyncPromptAuthNotifyCallback in mivExchangeAuthPrompt2.js:306)
1st-setup:2017-4-5 22:22:27.144:mivExchangeAuthPrompt2: asyncPromptAuthNotifyCallback: username=email@example.org (_asyncPromptAuthNotifyCallback in mivExchangeAuthPrompt2.js:319)
1st-setup:2017-4-5 22:22:27.145:mivExchangeAuthPrompt2: asyncPromptAuthNotifyCallback: WWW-Authenticate:Negotiate (_asyncPromptAuthNotifyCallback in mivExchangeAuthPrompt2.js:328)
1st-setup:2017-4-5 22:22:27.145:mivExchangeAuthPrompt2: asyncPromptAuthNotifyCallback: WWW-Authenticate:NTLM (_asyncPromptAuthNotifyCallback in mivExchangeAuthPrompt2.js:328)
1st-setup:2017-4-5 22:22:27.146:mivExchangeAuthPrompt2: getPassword: A realm was specified:Exchange Web Service (_getPassword in

In my setup with TB 52.1.0 and EC 4.0 (my dev), my log contains instead after the XLM HTTP Request was send():

1st-setup:2017-4-5 23:3:23.773:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf: ecnsIAuthPrompt2.getInterface: Ci.nsILoadContext
1st-setup:2017-4-5 23:3:23.773:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf: ecnsIAuthPrompt2.getInterface: Ci.nsILoadContext
1st-setup:2017-4-5 23:3:23.774:  >>>>>>>>>>> SUBMIT THIS LINE TO https://github.com/Ericsson/exchangecalendar/issues: ecnsIAuthPrompt2.getInterface({70d2b4fe-a552-48cd-8d93-1d8437a56b53})
1st-setup:2017-4-5 23:3:23.775:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf: ecnsIAuthPrompt2.getInterface: Ci.nsILoadContext
1st-setup:2017-4-5 23:3:23.775:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf: ecnsIAuthPrompt2.getInterface: Ci.nsILoadContext
1st-setup:2017-4-5 23:3:23.776:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf: ecnsIAuthPrompt2.getInterface: Ci.nsILoadContext
1st-setup:2017-4-5 23:3:23.777:  >>>>>>>>>>> SUBMIT THIS LINE TO https://github.com/Ericsson/exchangecalendar/issues: ecnsIAuthPrompt2.getInterface({1040ebe3-6ed1-45a6-8587-995e082518d7})
1st-setup:2017-4-5 23:3:23.777:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf: ecnsIAuthPrompt2.getInterface: Ci.nsIApplicationCacheContainer
1st-setup:2017-4-5 23:3:23.778:  >>>>>>>>>>> SUBMIT THIS LINE TO https://github.com/Ericsson/exchangecalendar/issues: ecnsIAuthPrompt2.getInterface({0d6ce59c-ad5d-4520-b4d3-09664868f279})
1st-setup:2017-4-5 23:3:23.778:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf: ecnsIAuthPrompt2.getInterface: Ci.nsILoadContext
1st-setup:2017-4-5 23:3:23.779:f8007443-677b-4b47-b328-62ed77b1b936: : ExchangeRequest.loadstart
1st-setup:2017-4-5 23:3:23.784:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf: ecnsIAuthPrompt2.getInterface: Ci.nsILoadContext
1st-setup:2017-4-5 23:3:23.786:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf: ecnsIAuthPrompt2.getInterface: Ci.nsILoadContext
1st-setup:2017-4-5 23:3:23.786:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf: ecnsIAuthPrompt2.getInterface: Ci.nsILoadContext
1st-setup:2017-4-5 23:3:23.902:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf: ecnsIAuthPrompt2.getInterface: Ci.nsIProgressEventSink
1st-setup:2017-4-5 23:3:23.903:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf:   --- ecnsIAuthPrompt2.onStatus: STATUS_SENDING_TO of myanonymezed.provider
1st-setup:2017-4-5 23:3:23.903:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf: ecnsIAuthPrompt2.getInterface: Ci.nsIProgressEventSink
1st-setup:2017-4-5 23:3:23.904:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf:   --- ecnsIAuthPrompt2.onProgress: this is a nsIChannel
1st-setup:2017-4-5 23:3:23.904:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf:   --- ecnsIAuthPrompt2.onProgress:2580 of 2580
1st-setup:2017-4-5 23:3:23.906:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf: ecnsIAuthPrompt2.getInterface: Ci.nsIProgressEventSink
1st-setup:2017-4-5 23:3:23.906:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf:   --- ecnsIAuthPrompt2.onStatus: STATUS_WAITING_FOR of myanonymezed.provider
1st-setup:2017-4-5 23:3:23.945:e29d8b9c-8a7f-4857-a39a-0dfa87a85fcf: ecnsIAuthPrompt2.getInterface: Ci.nsILoadContext
1st-setup:2017-4-5 23:3:23.950:f8007443-677b-4b47-b328-62ed77b1b936: : ExchangeRequest.progress. loaded:0, total:0
1st-setup:2017-4-5 23:3:23.951:f8007443-677b-4b47-b328-62ed77b1b936: : ExchangeRequest.onLoad :load, readyState:4, status:401
1st-setup:2017-4-5 23:3:23.951:f8007443-677b-4b47-b328-62ed77b1b936: : ExchangeRequest.onLoad :Server: Microsoft-IIS/8.5
request-id: 93ed28ac-b854-46c7-90d0-ed428e452127
WWW-Authenticate: Negotiate
NTLM
X-Powered-By: ASP.NET
X-FEServer: CAS03
Date: Fri, 05 May 2017 21:03:23 GMT
Content-Length: 0

1st-setup:2017-4-5 23:3:23.952:f8007443-677b-4b47-b328-62ed77b1b936: : ExchangeRequest.onLoad :

This second log means that the XML HTTP Request first response hasn't been intercepted by the mivExchangeAuthprompt2.js code and it was directly used inside the ecExchangeCalendar.js. It means that we have currently an issue in the callback glue between these two components and we need to investigate more inside the function ecnsIAuthPrompt2 from the ecExchangeCalendar.js which is the notificationCallback attached to the nsIHTTPChannel of the XML HTTP Request.

[rkent]

Here's my latest attempt:

http://mesquilla.net/betas/exchangecalendar-3.9.0y.xpi

This works for me with both Basic and NTLM authentication on TB 52. Autodiscover still does not work for me, but I'm not sure if that is new. I have not tested this on earlier versions of TB but I have no reason to expect it would fail there.

Generally what I did is used an http-on-modify-request observer to capture the html request and reverse the change of bug 1221320 so that auth prompts do get called as before, and the logic of this addon can be used.

You probably only experience this issue if you are using NTLM authentication and not supporting Basic.

[nunof]

Hello,

This is the first tentative fix I try and it does indeed work for me. Only comment is that it only with domain\username format (not username and domain in separate input boxes).

Many thanks,

Nuno Filipe Ferreira mobile: +351 91 289 15 43 | skypeid: nuno_f_ferreira

(whisper https://whispersystems.org/) Let's switch to signal http://sgnl.link/1KpeYmF

On 07-05-2017 06:18, R Kent James wrote:

Here's my latest attempt:

http://mesquilla.net/betas/exchangecalendar-3.9.0y.xpi

This works for me with both Basic and NTLM authentication on TB 52. Autodiscover still does not work for me, but I'm not sure if that is new. I have not tested this on earlier versions of TB but I have no reason to expect it would fail there.

Generally what I did is used an http-on-modify-request observer to capture the html request and reverse the change of bug 1221320 so that auth prompts do get called as before, and the logic of this addon can be used.

You probably only experience this issue if you are using NTLM authentication and not supporting Basic.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Ericsson/exchangecalendar/issues/580#issuecomment-299683135, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3cm3aWM-WheHBPKVkGF9GbFOKw5t8Sks5r3VQWgaJpZM4Mz4q_.

[oaxjogi]

Autodiscover still does not work for me, but I'm not sure if that is new.

It didn't work for me in the past. I assume it was not completely ok also in older versions.

After installing the .xpi I have no calendar entries anymore in my Exchange calendars, only in the CalDAV ones :-(

[bren-m]

Unfortunately 3.9.0y.xpi doesn't work for me. I get a 401 for both manually supplied credentials and autodiscovery

[kruess]

Did some tests with EWS 3.9.0y on TB 52.1.0, Lightning 5.4.1 and it works with autorecovery but only, when using the UPN syntax (username>@<domain) in the username field.

[bren-m]

3.9.0y.xpi does connect to Exchange when I use xxx@yyy.com in the username field as kruess suggested allowing me to view my calendar however I cannot:

1) Accept / decline an invite: I can send an accept or decline response however the meeting remains unconfirmed in my calendar and the sender does not receive the response.

2) Create a new meeting: When I attempt to create an invite, I cannot select 'Invite Attendees'. The button does not respond.

Issues 1) and 2) are something that I saw with the original 3.9.0 and Thunderbird 45.

[jretxaniz]

With the latter .xpi contributed by rkent I can reconnect to my Exchange calendar, but we received a message that says "Only the user availability status for the mailbox calendar will be visible." And in fact, all previous items appears with the only legend of "Busy". But I think is a step on the rigth direction.

[jhenkehd]

No improvement for me with 3.9.0y from above. My calendar is completely empty, in the error log there are errors related to, that it could not find the root element in /owa/exchange.aspx.

[jan-kiszka]

@rkent Your version helped here as well, but only after commenting out the if (lastAuthentication != "NTLM") block completely - the last auth was apparently not (or no longer) set to NTLM. This logic will likely need more tuning. Thanks!

[RogerSolerV]

3.9.0y worked for me! many thanks @rkent
Setup is: Thunderbird 52.1.0 Exchange Provider 3.9.0y

Connecting to a Microsoft Exchange version: 14.3.123.0 from local intranet network

[jeichberger]

Thank you @rkent - your version 3.9.0y is working perfectly here! With the other versions, I couldn't add the calendar (autodiscovery failed and the next-button was grayed out), but now everything works as it should.

Windows 10 Thunderbird 52.1.0 Lightning 5.4.1 Exchange Provider 3.9.0y

EDIT: same as @sleeksorrow - too early. Only works if I don't save the password, otherwise the calendar is read-only and empty when I restart Thunderbird.

[jretxaniz]

Where can i download Lightning 5.4.1?? I work with this now: lightning-5.4-sm+tb-windows.xpi and it doesn't work for me. Thanks

[tink3r]

3.9.0y works for me. Thnx @rkent! Setup: TB 52.1.0 (32-Bit) Lightning 5.4.1

[andrewperrin]

3.9.0y works for me as well, with the same problems brenboy reports above. However these are different problems, I suspect not related to the password-prompt issue.

[peshane]

Trying the xpi v3.9.0 but same problem for me: can't add my office365 calendar, error http 401 (with "Code: -19" when testing connection.

linux TB 52.1.0 (64 bits) lightenig 5.4.1

[efa]

Lightning 5.4.1 is packaged with: Thunderbird 52.1.0 see: https://developer.mozilla.org/en-US/docs/Mozilla/Calendar/Calendar_Versions

[nunof]

+1

Nuno Filipe Ferreira mobile: +351 91 289 15 43 | skypeid: nuno_f_ferreira

(whisper https://whispersystems.org/) Let's switch to signal http://sgnl.link/1KpeYmF

On 09-05-2017 09:12, Jan Kiszka wrote:

@rkent https://github.com/rkent Your version helped here as well, but only after commenting out the if (lastAuthentication != "NTLM") block completely - the last auth was apparently not (or no longer) set to NTLM. This logic will likely need more tuning. Thanks!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Ericsson/exchangecalendar/issues/580#issuecomment-300093448, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3cmxXAw0kHoqQe23Rcq05JiCYb0PEUks5r4B_ygaJpZM4Mz4q_.

[efa]

http://releases.mozilla.org/pub/thunderbird/releases/52.1.0/

[sleeksorrow]

3.9.0y worked for me too on TB 52.1.0 64-bit, thank you @rkent!

I needed to use user@domain syntax, as domain\user failed for me.

EDIT: Well, too early.... if I save the passwords in manager, then after restarting TB, calender is read-only and empty. Only if I don't save them so I need to enter them every TB start, it works.

[peshane]

@jan-kiszka Same as you, have to comment the "if (lastAuthentication != "NTLM")" block completely in components/ecExchangeRequest.js and it's now working. Thx to you and @rkent

[jhenkehd]

I can confirm what @peshane wrote, the whole block needs to be commented out, then it works again.

[cricog]

@rkent 3.9.0y worked too. Thanks @rkent !

I also needed to use user@domain syntax, as domain\user failed for me. (Thanks for the tip @sleeksorrow)

Thunderbird 52.1.0 (32 bits) Lightning 5.4.1

[sleeksorrow]

Yes @jhenkehd, it seems that removing the "if (lastAuthentication != "NTLM")" block fixed it for me, too.

[efa]

here work with vanilla 3.9.0y using user@domain in both: Primary email address Username and leave grayed Domain name

[JohnSPeach]

Looks like 3.9.0y is working for me with the removal of that block of code in components/ecExchangeRequest.js

[axelrathey]

Hi, it works for me as well after removing the "if (lastAuthentication != "NTLM")" block from ecExchangeRequest.js It works for calendar and addressbook as well. I have used autodiscover to configure it. Thanks to all the community, that was great work. May there is anybody with write access, which can upload this xpi to the offical github-location of this addon as current beta 3.9.1

Axel

[oaxjogi]

After switching the settings from username to email (with @) vanilla 3.9.0y works here with TB 52.1.0 64 Bit on macOS Sierra (10.12.4) - GREAT!