This PR adds SMTP OAuth2 support in Global Configuration for outgoing mail on 6.2-dev.
Implemented changes:
New mailer value: smtpoauth2
OAuth2 token issue/check flow in com_config
Provider support: Microsoft, Google, Custom
Microsoft tenant mode: common and tenant-specific
XOAUTH2 SMTP integration in mail factory
PHPCS/CS fixes in touched files
Important Clarification (Review Feedback)
The previous provider-specific legacy wrappers (m365auth, m365callback, m365checktoken) were removed/adjusted because there was no real historical route contract to preserve in core.
Security / Callback Flow Notes
OAuth flow is initiated from authenticated administrator context (com_config).
Callback state is validated against session (com_config.oauth2_state) using hash_equals.
If state/session is missing or invalid, callback exits with invalid token error.
Token persistence requires admin privileges (core.admin check) before writing config.
Testing Instructions
Login to Administrator.
Open Global Configuration -> Server/Mail settings.
Set mailer to smtpoauth2.
Configure provider credentials for one provider:
Microsoft (common tenant)
Microsoft (specific tenant)
Google
Custom
Click token issue button and complete provider consent.
Verify redirect returns to admin config and token timestamp is set.
Run token validation action.
Send test mail from Global Configuration.
Repeat for at least one additional provider profile.
Expected Result
OAuth flow completes only with valid admin session + valid state.
Refresh token is saved successfully.
Token check reports valid access token response.
SMTP test mail works with XOAUTH2 configuration.
CI style checks pass.
Actual Result
Behavior matches expected result for tested provider configurations.
6.2 PR now uses correct head branch and updated formatting/documentation.
Documentation Changes
This PR description now documents:
callback auth/session assumptions
state validation behavior
required test flow for provider scenarios
AI Disclosure
AI assistance was used to help draft/refine parts of implementation and PR text.
All code, behavior, and security assumptions were manually reviewed and tested by the author before submission.
Please fill out the PR form correctly, especially the AI disclaimer. Also please format your text correctly. Right now the description is hardly readable.
Why do you have custom routes for the different providers as legacy fallback, when they never existed in the first place? Your docblocks are incomplete. How do those callbacks against the admin com_config work, when the calling provider is not an authorised user? Seems to me as if that would fail. This needs at least documentation on how to use and test in this PR.
Please fill out the PR form correctly, especially the AI disclaimer. Also please format your text correctly. Right now the description is hardly readable.
Please fill out the PR form correctly, especially the AI disclaimer. Also please format your text correctly. Right now the description is hardly readable.
Why do you have custom routes for the different providers as legacy fallback, when they never existed in the first place? Your docblocks are incomplete. How do those callbacks against the admin com_config work, when the calling provider is not an authorised user? Seems to me as if that would fail. This needs at least documentation on how to use and test in this PR.