feat(auth): add XOAUTH2 authentication support to ManageSieve client#7
Merged
Conversation
Member
|
Thank you, this is a very desirable addition! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds XOAUTH2 authentication support to the ManageSieve client,
following the same pattern already established in horde/Imap_Client
( Horde_Imap_Client_Password_Xoauth2 ) and horde/Smtp
( Horde_Smtp_Password_Xoauth2 ).
Context
Modern mail infrastructure requires XOAUTH2 for all protocols, including
ManageSieve (port 4190). Deployments using OAuth2/OIDC single sign-on
(e.g. Apereo CAS, Keycloak) cannot use password-based ManageSieve
authentication at all: no password is available, only an OAuth2 access
token. This PR is a prerequisite for a forthcoming OIDC authentication
infrastructure for Horde; without it, Sieve filter management in Ingo is broken
for XOAUTH2-only deployments.
This PR is self-contained and independent: it introduces no new
dependencies, does not change existing behaviour for password-based
authentication, and can be reviewed and merged on its own merits.
Changes
src/Password.php — new interface Horde\ManageSieve\Password ,
parallel to Horde_Imap_Client_Base_Password and Horde_Smtp_Password .
src/Password/Xoauth2.php — new class implementing the interface,
encoding credentials as per the XOAUTH2 spec
( base64("user={user}\x01auth=Bearer {token}\x01\x01") ). Identical
logic to Horde_Imap_Client_Password_Xoauth2 and
Horde_Smtp_Password_Xoauth2 .
src/Client.php — minimal additions:
• AUTH_XOAUTH2 = 'XOAUTH2' constant
• 'XOAUTH2' added to $supportedAuthMethods
• 'xoauth2_token' parameter in constructor defaults
• getParam('xoauth2_token') — resolves a Password object to its
encoded string, or returns the raw value
• Constructor triggers connect+login when xoauth2_token is set and
no password is provided
• _cmdAuthenticate() dispatches to _authXOAUTH2() when method is
AUTH_XOAUTH2
• _authXOAUTH2() — sends AUTHENTICATE "XOAUTH2" "{token}"
All existing code paths for password-based authentication are
unchanged.
Architecture note
horde/Smtp has been refactored to use dedicated Authenticator and
Credentials classes, while Horde_Imap_Client and horde/ManageSieve
both use the classic inline authentication pattern in Client.php . This
PR intentionally stays within the existing Client.php architecture.
Refactoring Client.php to match the Smtp pattern would affect all
authentication methods (PLAIN, LOGIN, DIGEST-MD5, CRAM-MD5, EXTERNAL)
and is out of scope here — that work is better addressed in a dedicated
PR.
Compatibility note
If the server does not advertise XOAUTH2 in its SASL capabilities,
_getBestAuthMethod() will throw the existing
Horde\ManageSieve\Exception — same behaviour as for any unsupported
method.
Tests
test/Unit/Xoauth2Test.php — unit test for the
Xoauth2 password class, modelled after the equivalent tests in
horde/Imap_Client and horde/Smtp .