HTTP error response gets truncated

Created on 8 August 2024, 5 months ago

While debugging a mail configuration, in one instance a truncated error was logged.

GuzzleHttp\Exception\ClientException: Client error: `POST https://login.microsoftonline.com/[...]/oauth2/v2.0/token` resulted in a `401 Unauthorized` response: {"error":"invalid_client","error_description":"AADSTS7000215: Invalid client secret provided. Ensure the secret being se (truncated...) in GuzzleHttp\Exception\RequestException::create() (regel 113 van /var/www/html/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php).

To reproduce this, enter an invalid client secret. Other errors were logged correctly.

I temporarily solved this by adding $msg = $e->getResponse()->getBody()->getContents(); and setting a breakpoint, so I have no patch to provide.

🐛 Bug report
Status

Active

Version

2.0

Component

Code

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @woutgg
  • 🇮🇹Italy apaderno Brescia, 🇮🇹
  • Status changed to Postponed: needs info 5 months ago
  • 🇮🇹Italy apaderno Brescia, 🇮🇹

    Does the exception message literally contains (truncated...)?

  • Yes, the text I quoted is the literal message in the log entry.
    The full message does still exist though, as I could access it via the temporary statement I mentioned.

  • 🇮🇹Italy apaderno Brescia, 🇮🇹

    The client secret is intentionally not logged, similarly to what Drupal core does which does not log the previous or the current password when an account password is changed.
    The exception is logged just to make possible to understand what happened (in this case, that an invalid client secret has been provided). The correct client secret can be retrieved from the Microsoft Azure portal.

  • I see, that makes sense.
    In my case, I had no access the Azure portal itself and a bit of potentially important information was also truncated: namely the suggestion that secret key and secret ID might have been swapped (I do not have the exact message at hand). Additionally, seeing the client secret in the full message helped me to be more confident I did not misconfigure the module itself.

    I agree that in the choice between this shortcoming and revealing the client secret, the latter if probably more important in most cases.
    Perhaps an override toggle might be useful though, to enable in a dev environment for instance?

  • 🇧🇪Belgium borisson_ Mechelen, 🇧🇪

    While I could see it being valuable to help in debugging the problem, I think the chosen route here makes sense and for that reason I think the behavior should stay as-is. I suggest closing this issue as won't fix.

Production build 0.71.5 2024