https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #60 from Olivier Hubert <olivier.hubert@inlibro.com> --- (In reply to David Cook from comment #59)
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.
Yes, I agree that all this is possible and the way to go. The problem I see is that the SMTP server configuration, and so eventually the web authentication, is / will be done through smtp_server.pl. If we allow that page to configure the Transport and not the SMTP::Server instance, then we are forever coupling Transport::OAUTH and SMTP::Server. In that case, I don't really see the need to have a separate entity for Transport::OAUTH if it needs to always work in conjunction with SMTP::Server. I think you have summed up pretty well how will work, with a cronjob for the refresh token, etc. I'm just curious as to why we need two separate classes if we're linking them so deeply. I might be trying to solve a non-issue. I'm not sure how the relationship between different classes is managed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.