https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #19 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- (In reply to Thomas Klausner from comment #18)
We have a customer that will need XOAUTH support for mailing soon (as they are using MS365, and they will disable basic SMTP).
They might go with the external proxy solution (simonrob/email-oauth2-proxy), but they are actually interested in getting proper XOAUTH support into Koha. And are (maybe) willing to sponsor the development (depending on how much it will be).
We are currently preparing an offer for the following steps:
* First step: Add XOAUTH support to the Koha SMTP sender * all the hard parts are already available on CPAN: LWP::Authen::OAuth2, Authen::SASL::Perl::XOAUTH2 and Email::Sender * we "just" need to add some new config settings to SMTP to allow using an access-token (instead of username/password) * we will also need to set up a cronjob to refresh the access tokens and the refresh token (better via cronjob, because if the mail sending happens infrequently even the refresh token could be invalidated in the interval where nothing happend) * The XOAUTH setup (i.e. the OAuth handshake to login the service account and create a first refresh token) will be done via a command line script * Second step (optional): * Add a GUI to the Staff interface to setup XOAUTH and do the OAuth handshake (so system librarians can do the setup without needing access to the shell) * Probably do this via a plugin
The second step will be very likely outside the budget of the client, and even the first step might be too much. In that case we (HKS3) would try to get further funding by other interested libraries.
Of course we would very much like to get this changes into the Koha core or at least into a plugin, though AFAIK the Notifications-Area does not support any plugins/hooks as of now. We would need some feedback / discussion on how to actually add this feature to Koha: Just add it to Core, or add a way to Koha core to add this (and later other protocols) via Plugin.
Looking forward to some feedback to getting this feature (that will be needed more often in the future, as more and more email providers move away from plain SMTP) into Koha!
The token should be retrieved (if a refresh is needed) when it's going to be used. I don't think we need a cronjob here. Making the API call to retrieve a fresh token, if it has expired or absent, could be done during the sending session. I initially thought of implementing an Email::Sender::Transport class based on the persistent SMTP one. So all the session shares the same token and it gets retrieved in a more generic way. The caveat is you wouldn't have a 'Koha context' in such generic transport, thus not possible to store it on the DB, etc. Excited someone can devote time to accomplish this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.