Error Handling 'MailboxNotEnabledForRESTAPI' made more difficult

[pruggiero]

I'm struggling with the below sections of code from the lib/strategy.js

    /* Specific case where a user creates a new Outlook account via the OAuth screen
     * and the redirect back to the application bypasses M$'s account finalisation
     * process, giving you an Outlook account with no Mailbox entry.
     */
    if (res && res.statusCode === 404) {
        return done(new OutlookAPIError(res.headers['x-caserrorcode'], res.statusCode));
    }

This code catches multiple scenario's like when the account has no mailbox or the account's office license has expired, its a fairly common issue. I want to be able to handle this error in specific ways and direct the user to use another provider given they can't use the Outlook API or at least provide information of possible causes.

Since this is catching the error and not using my verify callback, it makes handling this case more difficult. I was thinking of opening a PR that sets a flag to bypass this check, but I really think this error should be dealt with in the verify callback and this code should just be removed. Without it being there all that occurs is we get a bad profile, which is a possibility that I already need to handle. It just feels like this section of code covers too many possible failure cases.

Curious if others have encountered similar issues.

[clocked0ne]

A strategy really should not be making decisions based on responses, that has to be down to the individual developer / business logic. That said, I have had to handle the scenario where the user has no Mailbox, just an MS account (or it is not yet enable for the REST API) and it was easily identified in the 'bad' profile. As our service also offers GMail support we could offer this as an alternative, but not everyone using this library will be of the same circumstances or opinion of how it should be handled.

It would be interesting to hear from the wider community using this if they have faced similar issues; I would welcome non-breaking creative suggestions on means of handling these responses.