Simplified interface to add calendar and password dialogs

[Trim]

In order to have a simpler way to create calendar and to have a more reliable way to ask password to users, I plan to update the calendar creation dialog and calendar properties.

Tasks I identified to achieve this:

• Modify the Exchange Request standard component to allow pass password as argument
• Modify Auth Prompt Manager interface to allow set password manually
• Modify Exchange Settings Overlay XUL to split current standard UI into two independent dialogs (to be able to insert them separatly)
  • Create an exchangecalendar authentication dialog (alias "ecauth") to ask:
    • user domain name (in one field as new NT technologies support the style user@domain.com since years)
    • user password (to avoid current bugs where password dialogs doesn't appear and where we don't know if we have to give user domain password or mailbox folder password)
    • select a server configuration type (autodiscover, office 365 or manual configuration)
    • according to server configuration type, ask a Exchange Web Service URL
    • add a final configuration test button to auto discover configuration if needed (and if successfull set EWS URL and update type to manual) and allow to pass to next screen if authentication were successfull
  • Create an exchangecalendar folder selection dialog (alias "ecfolderselect") to ask:
    • Owner folder (mailbox to look for data)
    • Select root folder (Calendar, Task, Addressbook) and path as current dialog do
    • Check access is available for previously configured user (not sure if this step is needed)
    • Save all settings on finish (don't forget to save password as it's a new field)
• Modify Exchange Settings Overlay Javascript to handle new screens
  • Handle ecauth dialog
    • Add a way to validate user, password, Web Service URL
  • Handle ecfolderselect dialog
    • Add a way to validate folder access before saving
• Modify Echange Calendar Creation dialog to use new available interface from Exchange Settings
  • Add wizard page for ecauth dialog
  • Add wizard page for ecfolderselect dialog
• Modify every XUL where Exchange Settings Overlay is used (list of XUL to determine)

I'm currently working on my personal branch Trim/wip-new-calendar-creation-dialog-and-authentication-process. I don't work directly on ExchangeCalendar repository, because I'll certainly rebase the branch multiple times and/or force push commits.

[advancingu]

Sounds great! Would you be able to upload a screenshot here of how the new UI looks?

[Trim]

Yep.

So here a use case: I'm adrien and I want to see calendar of my colleague "m".

1. I ask to Thunderbird to create a new, calendar
2. I select "Network Calendar"
3. I select "Microsoft Exchange…"
   
4. On next page, I choose calendar name, calendar color… as usual
   
5. Next, I have to give my credentials on the Exchange Settings server (test button is greyed until an email address, a password and an Exchange Web Service URL are setted)
   
6. I click on test button: exchangecalendar will use given settings to reach Exchange server and try to access my own calendar folder (that was the simpler test to create). On success, I can click "Next":
   
7. Now, I set from which user I want to read calendar (previously named "mailbox", now "Folder owner"). I have to check existence of the owner, before continue:
   
8. My colleague "m" exists, but I have only access to its availability
   
9. Click on next button should check folder access, but I didn't implemented a real test currently IIRC:
   
10. Finally, click on next and the standard "Calendar created" dialog is shown :)
    

Sorry, for the French / English translation mix, I had troubled Thunderbird / Lightning :)

Note, on step 5, you can ask directly to save password inside your password manager.
If you don't, password will be saved in exchange calendar cache and it will be asked only on Thunderbird restart.
There, you can also choose "Manual configuration" or "Auto discovery configuration" for server type.

[advancingu]

Hi @Trim, all the images fail to load. Are you sure they were properly saved / uploaded?
Also, no worries about the language mix. I speak both languages.

[Trim]

Hello,

I have updated links to give direct access to the nextcloud share (before, links were created from the gallery app).

If it still not work, you can download a zip with all images here (so, you bypass the Gtihub cache):
https://cloud.adorsaz.ch/index.php/s/eR4QINs3V5VtMuZ

[advancingu]

Thanks, the images now show in Github as well.

From a user experience perspective, I think the dialogues can be simplified even more:

• In number 5, I would remove the Test authentication settings button and perform the validation when Next / Suivant is clicked. If the credentials are incorrect, simply don't proceed to the next screen and highlight the input box with an error.
• Also in number 5, I would not show the server URL label and input box at all unless the Server configuration drop-down is set to a value that implies manual URL input. This reduces visual noise.
• In number 7, if you perform the owner check when the Next / Suivant button is clicked and remove the Look for owner ... button, the flow should also get cleaner than before. Then change screen 8 to simply be about selecting the desired folder but with the owner and share already fixed (from step 7). As before, I would also remove the test button and do the check on the Next / Suivant button, preventing the next step if user input is wrong.

[Trim]

For the Test... buttons, I've just checked the wizard documentation and it seems to be doable with the onwizardnext event. I'll try it.

Indeed, I can hide Server configuration part in number 5 for Office 365, that will be easy (it's already done for Autodiscovery).

For last point, you suggest to split the configuration into one more step like authentication → mailbox/share selection → folder selection ? That makes sense for me now :)

[advancingu]

Great.
Great.
Yes. I think it's worth a shot as long as only a minority of users want to try out different shares and would therefore have to go back and forth all the time.

[naevtamarkus]

Hi, I don't know if I arrive too late for this... but can I ask for the password prompt screen to be compatible with the KeePass password manager? I really don't want to leave my clear-text passwords in Thunderbird's store.
Thanks!

[advancingu]

@naevtamarkus You mean Ctrl + V paste support for both (username, password) fields in one batch? I would assume most people use the account creation screen very rarely, so I wouldn't consider a change for this screen a high priority. It should also go in its own feature request.

[naevtamarkus]

No, what I mean is that the password is not recorded in the account creation screen, so that it would be asked every time you start Thunderbird... and this is where the password managers (like KeePass) come into play, so that they can auto-fill the password and "click" enter automatically. This is standard procedure (works for 99% of the applications), and Thunderbird supports it on all its accounts... but the fork this project comes from has never allowed it (so, it was basically the only password I needed to type). I just hope someone is considering this for the near future. Thanks!

[Trim]

Hello,

Well, you can see I've added in part 5 a way to directly enter username and password inside the calendar creation. I've done this because the current interface is very complex for a new user : what's the difference between mailbox and user name, domain name ? There's no password field to go through Exchange server data ?

Having a screen which directly ask for username, password and server location is, I hope, clearer of what is currently happening: we are trying to connect to your Exchange server to be able to get data from it.

I have added also a checkbox to directly save the password in the standard Thunderbird password manager on success authentication. If you don't want to use it, just let it opt-out and on next Thunderbird start you'll see same prompts than the original fork.

---

The issue you mentioned is not really in the same process: it's when you have already configured your calendar and you start Thunderbird with no password saved in the manager.

In that case I've not made any modification, because:

1. ExchangeCalendar requires to have your password in its own cache, otherwise you'll be prompted every 15 minutes to synchronize Thunderbird with the server. To do that, ExchangeCalendar code currently extends the XUL AuthPrompt2 interface, because the one from Thunderbird don't have any implementation of such password session cache.
2. ExchangeCalendar code requires to extend the XUL AuthPrompt2 also to be able to manage automatically the authentication type: it tries to send HTTP Basic Authentication messages and if it fails (by looking for headers inside HTTP answers), it tries to run NTLM ones.
3. ExchangeCalendar code also intercepts HTTP handshakes (inside the ecExchangeRequest.js code) to check if we have received HTTP redirections and to run password prompts at the right moment.
4. ExchangeCalendar code is currently able to give you a password prompt with details of which user and server requires a password: I didn't see such details in standard Thunderbird password prompts.

That's just to explain what I've seen up to know (maybe I'm wrong with some points, because I am not very skilled with all the XUL/JavaScript/interfaces stuff), but that the current situation of the XML HTTP Requests sent to Exchange servers and password prompts to user.

Unfortunately, to modify this code of ExchangeCalendar will requires strong knowledges about Exchange 2007, 2010, 2013 and next releases authentication process, knowledges about XML HTTP requests and how to correctly manage authentication types and finally about XUL interfaces to see if new interfaces can be used now to get equivalent features.

Fortunately, you can also just use the Thunderbird password manager with a master password (in that case, passwords will be encrypted). You can then simply use Keepass to give the master password to Thunderbird.

So, regarding how much complex task will be to update our code to use standard Thunderbird password prompt and how simple workaround is, it's not a priority for me (if it's feasible).

[naevtamarkus]

Thanks a lot for your detailed response.

I think it's a cosmetic issue about the way windows are named, so that KeePass (KeeFox) can recognize them. Please check here: Ericsson#384

Anyway, the workaround you propose (using the master password) is sufficient in my case, I don't know how did I overlook this feature.

Thanks a lot!

[advancingu]

Hi @Trim, any news on this? Looks like you already did a large part of the implementation so it would be great to see this finished up and ready for merging.

[Trim]

No news about this proof of concept.

I'd prefer to finish the currently waiting big modifications (beautify all the code and update the code tree #80). Then I'll be able to take back this code manually and create a better commit history to do a pull request (that will be a really big pull request as IIRC almost all the code interface is rewritten).

I have too to check if code still work correctly with stuff like primarySMTP as I understood this summer that's an important tool used by Active Directory (and so, Exchange).