OWA: Login is not saved

[benbucksch]

Reproduction

1. Set up OWA account ben@bexchange
2. Login
3. Restart Mustang
4. Click on account and its Inbox
5. Click on [Get mail] again

Actual result

• After step 3, the account shows as logged out (icon: letter with x)
• After step 4, you see an orange error "Please login"
• After step 5, you see the OWA login window. You have to manually enter the username and password.

Expected result

• After step 3, the account is logged in
• After step 4, you get new mail.
• If you were logged out before, you see the OWA Login window, not "Please login" error.

[NeilRashbrook]

(The correct step 4 is to click on Posteingang.)

[benbucksch]

Right, clicking on INBOX = the folder, not the account, yes.

[NeilRashbrook]

Note that regular OWA won't let you stay logged in after a restart; this feature is limited to the "Stay Logged In" option of Office 365.

[benbucksch]

regular OWA won't let you stay logged in after a restart

How would OWA know about a restart? Are you saying that these are session cookies? Can we tell the browser to make them persistent cookies?

[NeilRashbrook]

Of course they're session cookies. They've always been session cookies. We looked at this in Owl five years ago, but nothing ever came of it, presumably because its auto-login content script was good enough. But there's some code on GitHub that might work. (I say might because it assumes there's only one partition and that you have somewhere to control adding the cookie listener.)

[benbucksch]

So, in Owl, with OWA, we:

• Do background login, by submitting the login form directly in the background, without UI - esp. for on-premise Exchange with standard login form
• For Office365 and similar login forms, we open the window, but fill in the email address and password automatically.

In combination, that saves the user from having to log in manually, in many cases. So, we need the same in Mustang, for the login at startup to work.

[benbucksch]

Use the Owl source code to implement this.

[jermy-c]

Do background login, by submitting the login form directly in the background, without UI - esp. for on-premise Exchange with standard login form

This is already implemented by Neil on neil/owa-login-in-background but not working as it yet doesn't detect any forms.

For Office365 and similar login forms, we open the window, but fill in the email address and password automatically.

This is already implemented by Neil on neil/owa-fill-login-window but it doesn't for personal accounts.

[NeilRashbrook]

Do background login, by submitting the login form directly in the background, without UI - esp. for on-premise Exchange with standard login form

This is already implemented by Neil on neil/owa-login-in-background but not working as it yet doesn't detect any forms.

I just tried it again and it worked first time for me with the ben@bexchange.net account. It's known not to work with Office 365 accounts though, which is why we have the fill-login-window code..

For Office365 and similar login forms, we open the window, but fill in the email address and password automatically.

This is already implemented by Neil on neil/owa-fill-login-window but it doesn't for personal accounts.

There are at least three issues regarding personal accounts as compared to Office 365 accounts:

1. The DOM for entering the password is slightly different, as there is only one non-hidden input element, which is the password, so there is no username element, and the submit element is a button element rather than an input element.
2. I can't find any way of getting any change to the password to stick. If you programmatically change the value, the page will reset it after most DOM events e.g. focus, mouseover. I've tried dispatching input events but without success.
3. Rather than a pair of input elements, one type="submit" (stay signed in), one type="button" (don't stay signed in), the Stay Signed In page now uses two button elements, both type="submit", although they can be distinguished as they have accept or decline in their ids.

[jermy-c]

I can't find any way of getting any change to the password to stick. If you programmatically change the value, the page will reset it after most DOM events e.g. focus, mouseover. I've tried dispatching input events but without success.

I just found the following code for changing the password and not having it reset after DOM events. link here

const textToType = "testemail@email.com";      
var element = document.querySelector('form input');

//gets the value property setter from the original HTMLInputElement
var originalValueSetter = Object.getOwnPropertyDescriptor(window.HTMLInputElement.prototype, 'value').set;

//invokes the original setter over the specific element
originalValueSetter.call(element, textToType);

//fires the change event on the input element
element.dispatchEvent(new Event('change', { bubbles: true }));

//clicks the continue button...
document.querySelector('button.email-submit-button').click();

[benbucksch]

originalValueSetter = Object.getOwnPropertyDescriptor()

:laughing: Nice idea!

[NeilRashbrook]

Thanks, that works! I've updated my branch with the working code.

[benbucksch]

I've merged neil/owa-login-in-background to master, with changes, e.g. moving the login form code into a separate file.

Thanks, @NeilRashbrook !

[benbucksch]

I've also merged neil/owa-fill-login-window to master, with changes, e.g. moving to a new file, and putting the script into a proper function, instead of a big string.

git commit 81ae4807

[NeilRashbrook]

The problem there is that you're not quoting the substitutions any more, so if the password contains a " then the script will break.

[benbucksch]

Indeed, thanks for the info. Which chars do we need to escape for a "" string in JS? Only "? Which function do you recommend? Do you want to make a PR to fix it?

[benbucksch]

Or should we use

`$PASSWORD`

and then escape

`

with its hex code \HH ?