Help!!! WHMCS Find My Shared Mailbox, Please! - M365 import

[BENELUX]

Hey WHMCS Community

 

So here’s the thing… I love WHMCS. It’s great. But right now, it has a little “quirk” when it comes to shared mailboxes.

Imagine this: I’ve got my main mailbox doing its thing, happily bringing in emails. But then there’s the shared mailbox, the one that all the support team emails go to. WHMCS? It sees it… but then pretends it doesn’t exist. 😅

Here’s the geeky version:

• WHMCS currently uses /me/messages from Microsoft Graph API.

• This only fetches emails from the authenticated user’s mailbox. Shared mailbox? Nope, invisible.

• Even if Full Access is granted in Exchange and you’ve got all the delegated permissions like Mail.Read.Shared, WHMCS is like, “I don’t see anything here. Must be Monday.”

 

The right way (according to Microsoft Graph) is:

GET https://graph.microsoft.com/v1.0/users/{shared-mailbox}/mailFolders/inbox/messages

Yes, WHMCS, that mailbox does exist, and yes, I do have permission to read it.

What I’m asking:

• Can WHMCS please natively support shared mailbox imports?

• Guidance on exactly which delegated permissions are needed (so I don’t go on a wild goose chase for nothing).

• Support for the correct Graph API endpoint.

• Bonus points: documentation for optional PHP session settings for cross-site OAuth flows (because apparently, cookies are shy and need proper settings to stick around).

 

Expected outcome:

• Fetch emails from shared mailboxes without needing a license for it.

• Less headache, more sanity.

• WHMCS behaving like the email superhero it’s meant to be.

 

Anyone else banging their head on the “shared mailbox wall”? Let’s commiserate, share workarounds, and maybe get WHMCS to notice that shared mailboxes exist in the universe.

Thanks!

[slim]

Yeah, Ive hit this - had to license the mailbox - so it has a direct login.  😞

[BENELUX]

We’re going to go ahead and grab an Exchange Online license ourselves to get it working for now. Hopefully, WHMCS will notice shared mailboxes exist in the universe and improve native support ASAP.

[BENELUX]

UPDATE: We got it working!

For anyone else hitting the “Approval Required” wall when trying to connect a standard (licensed) Exchange user, we found the culprit.
We managed to solve this, but it required two specific changes due to how WHMCS is hardcoded.

1. The "Shared Mailbox" had to become a "Licensed User"
Because WHMCS hardcodes the Graph API call, it is technically impossible to access a Shared Mailbox via a delegate admin account.
*   The Fix: We converted the Shared Mailbox to a regular User Mailbox and added an Exchange Online license. This ensures that when we authenticate as that user,  correctly refers to the support mailbox.

2. We had to strip `prompt=consent` manually
Once we switched to a standard licensed user (non-admin), we hit the "Approval Required" wall during OAuth.
*   The Cause: WHMCS appends `&prompt=consent` to the auth URL, which forces a new consent prompt that standard users cannot accept (due to our Azure security policies).
*  The Workaround: By manually removing this parameter from the URL in the browser, Microsoft respected the Tenant-Wide Admin Consent we had already granted, and the connection went through immediately.

Summary:
If you are struggling with this, you cannot use a true Shared Mailbox with WHMCS right now. You must license it as a user and clean up the Auth URL to get it connected.

Hope this saves someone else the debug time! ☕️

[SVCode]

@BENELUX How do you strip the  `&prompt=consent` in the URL?

The address box isn't editable in the pop up - tried a few browsers - and if I copy/paste it into a new window, it doesn't seem to update the WHMCS window with the token.

[SVCode]

ChatGPT to the rescue - I had to use a hook to strip it out, all browsers I tried blocked editing the address bar (even after trying to avoid it with browser settings):

<?php
/**
 * Strip prompt=consent from Microsoft OAuth authorize URLs opened by WHMCS popups.
 * Upgrade-safe: lives in /includes/hooks
 */

add_hook('AdminAreaHeadOutput', 1, function ($vars) {
    return <<<HTML
<script>
(function () {
  function stripPromptConsent(url) {
    try {
      var u = new URL(url, window.location.href);

      // Only touch Microsoft login/authorize hosts
      var host = (u.hostname || "").toLowerCase();
      var isMicrosoftLogin =
        host === "login.microsoftonline.com" ||
        host.endsWith(".login.microsoftonline.com") ||
        host.endsWith(".microsoftonline.com");

      if (!isMicrosoftLogin) return url;

      var prompt = u.searchParams.get("prompt");
      if (prompt && prompt.toLowerCase() === "consent") {
        u.searchParams.delete("prompt");
        return u.toString();
      }
      return url;
    } catch (e) {
      return url; // if URL parsing fails, do nothing
    }
  }

  // Patch window.open (most popup flows use this)
  var _open = window.open;
  window.open = function (url, name, specs, replace) {
    if (typeof url === "string") {
      url = stripPromptConsent(url);
    }
    return _open.call(this, url, name, specs, replace);
  };

  // Also patch location.assign/replace in case WHMCS uses those
  try {
    var _assign = window.location.assign.bind(window.location);
    window.location.assign = function (url) {
      if (typeof url === "string") url = stripPromptConsent(url);
      return _assign(url);
    };
  } catch (e) {}

  try {
    var _replace = window.location.replace.bind(window.location);
    window.location.replace = function (url) {
      if (typeof url === "string") url = stripPromptConsent(url);
      return _replace(url);
    };
  } catch (e) {}
})();
</script>
HTML;
});

 

[BENELUX]

Hi @SVCode

I received a follow-up from WHMCS Support regarding this issue. They have confirmed that the `prompt=consent` parameter is the culprit preventing connections.

They provided me with a modified `MicrosoftAuthProvider.php` file that removes this parameter, and I can confirm this fixes the issue for us permanently on WHMCS 8.13.1.
Just to clarify on the workaround mentioned earlier: we did not copy the URL to a new tab (which likely breaks the session/state); we simply edited the URL directly in the current browser tab to remove `&prompt=consent` and hit enter.

However, for a permanent fix without manual URL editing, you will need the patched file. Since the file is IonCube encoded, you cannot easily edit it yourself.

The Solution:
I recommend opening a ticket with WHMCS support and referencing case WHMCS-24661. They should be able to provide you with the same 'MicrosoftAuthProvider.php' patch for version 8.13.1 that they sent me.
Once you have the file:
    1.    Backup your original  /vendor/whmcs/whmcs-foundation/lib/Mail/Incoming/Provider/MicrosoftAuthProvider.php 
    2.    Upload the patched file to the same location.
    3.    Re-authenticate your department using the Microsoft 365 licensed user.

Hope this helps you get yours connected!

MicrosoftAuthProvider.php

[SVCode]

Appreciate the reply - but my (ChatGPT) hook is doing what it needs to for me i.e stripping `&prompt=consent` 🙂

[WHMCS JoshQ]

Hi all,

I just wanted to advise that we are currently aware of another issue with MS365 authentication, which we believe is caused by a recent change that was made on Microsoft's end.

If you see a blank page after completing authentication with MS365 upon being redirected back to WHMCS's callback, it is most likely caused by the Cross-Origin-Opener-Policy (COOP) enforcement in your browser. It'll look like this:

A case is open to get a solution implemented on our end, but in the meantime there is a workaround.

Sadly, Chromium based browsers (Google Chrome, Brave, Edge, etc.) enforce COOP usage and do not provide a way to disable it. However, it is possible with Firefox, though you should only do this temporarily, as COOP is an important security feature. Open Firefox, navigate to about:config, search for browser.tabs.remote.useCrossOriginOpenerPolicy and set it to false. Once that's done, you should be able to complete the auth flow as expected. Once you've done that, make sure you re-enable COOP by setting that flag to true again.

As always, feel free to reach out to our Support team via ticket if you continue to experience issues.