https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #59 from David Cook <dcook@prosentient.com.au> --- (In reply to Olivier Hubert from comment #58)
(In reply to Tomás Cohen Arazi (tcohen) from comment #52)
I always felt we should implement an `Email::Sender::Transport::XOAUTH` module, maybe based on https://metacpan.org/dist/Amazon-SES/view/lib/Email/Sender/Transport/SES.pm
Do you mean that we should put all XOAUTH-related code in its own transport, and simply alternate between the Permanent transport and XOAUTH transport at send time, depending on the SMTP::Server configuration?
The transport is already stored on a per library basis, so it's not so much swapping between Persistent and XOAUTH, as just using the right transport for the right library.
The problem with this is that some XOAUTH flows require a web-based authentication. This needs to be done while configuring the SMTP server, as it cannot be done when sending emails. It's why I decided to integrate everything into SMTP::Server. If you have an idea on how to allow that authentication to work when setting up the server yet decouple XOAUTH from SMTP::Server, I am willing to try it.
So you could have an auth type in the Koha::SMTP::Server, and then in Koha::SMTP::Server->transport() you could choose the appropriate transport, and in the transport constructor you could check if the access token is expired. If it is, get a new one. With authorization_code grant, you'd have access to a refresh token, so you'd just use that for fetching a new access token. And if that fails, then you just have to fail overall anyway. The web-based authentication is a bit of a pain, but it shouldn't be a big drama. In practice, refresh tokens should last long enough on an active server, but we could put together a cronjob to fetch a new access token every night. So the initial setup of authentication_code grant is annoying but once it's set up then it should work fairly similarly to the client credentials grant at send time. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.