https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42870 --- Comment #18 from David Cook <dcook@prosentient.com.au> --- Comment on attachment 201963 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201963 Bug 42870: added field for JSON configuration and fixed XOAUTH2 plugin Review of attachment 201963: --> (https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=42870&attachment=201963) ----------------------------------------------------------------- ::: koha-tmpl/intranet-tmpl/prog/en/modules/admin/smtp_servers.tt @@ +129,5 @@
+ <li> + <label for="config" class="json">Configuration: </label> + <textarea name="config" id="config" cols="75" rows="10"></textarea> + <div class="hint" + >Server's configuration, in JSON. <button class="more btn btn-light" data-target="config"><i class="fa fa-caret-down"></i> [% tp("Show more information", "More") | html %]</button></div
Ideally, I'd rather not use a blob of JSON in the UI. I originally intended for the plugin to handle this via the Koha Plugin UI. Part of the reason is that I want the Koha Plugin to encrypt its secrets and not show/store them in plain text. My thinking there was that since we're passing the smtp_server object to the plugin, it can do a lookup against the smtp_server entry to use its "config" column. I made it JSON for the flexibility at the storage end during this more experimental stage, but I really really want to avoid that at the UI end. @@ +241,5 @@
[% END %] </li> + <li> + <label for="config" class="json">Configuration: </label> + <textarea name="config" id="config" cols="75" rows="10">[%- smtp_server.config | html -%]</textarea>
I haven't tried this out, but the "html" filter should escape double quotes, which would be a problem for maintenance of config. @@ +572,5 @@
+ const xoauth2_defaults = { + grant_type: "client_credentials", + client_id: "<enter client id>", + client_secret: "<enter client secret>", + scope: "https://outlook.office365.com/.default",
I'm on the fence about defaulting to a Microsoft scope here. I think this would be better placed in the Koha Manual. @@ +573,5 @@
+ grant_type: "client_credentials", + client_id: "<enter client id>", + client_secret: "<enter client secret>", + scope: "https://outlook.office365.com/.default", + token_url: "<enter complete token URL, with tenant ID if relevant>",
Tenant ID is also a Microsoft concept. ::: lib/Koha/Plugin/Core/Email/Transport/SMTP/XOAUTH2.pm @@ +91,5 @@
$sasl->callback(auth => $smtp_server->user_name); $sasl->callback(authname => $smtp_server->user_name); + $sasl->callback(user => $smtp_server->user_name); + $sasl->callback(pass => sub {
So you've improved and worsened the plugin by making this change hehe. If you look at https://metacpan.org/pod/Authen::SASL::Perl::XOAUTH2 you'll see it uses "user" and "pass" callbacks whereas Authen::SASL::XS uses user, auth, password, and pass callbacks. Maybe I should add a PR to Authen::SASL::Perl to get them to harmonize their callback mappings with the rest of Authen::SASL... looks like the older Authen::SASL::Cyrus also uses user, auth, password, and pass: https://metacpan.org/release/ADAMSON/Authen-SASL-Cyrus-0.13/source/Cyrus.xs#... Trying to remember why I included authname. Maybe because Cyrus SASL uses SASL_CB_USER, SASL_CB_PASS, SASL_CB_AUTHNAME in the C libraries. Maybe because technically it is an option: https://github.com/perl-authen-sasl/perl-authen-sasl-xs/blob/master/XS.xs#L8... -- You are receiving this mail because: You are watching all bug changes.