<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-AU link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>Hi Michael,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Another case where a Koha to Koha API would be useful is in the use of additional service (or microservices). At the moment, the SIP server is closely coupled with Koha, but it could just as easily be a separate component that used HTTP APIs (rather than internal Perl APIs) to work with Koha. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>You could argue that you could avoid auth (although I don’t understand your interpretation of MCV in this case), but that would be out of convenience rather than security. You could argue that you just protect the edges of your host (via a firewall for instance), but what about if that service isn’t running on the same host? Then you need to open a hole in that firewall. Then how do you protect that hole? Just using IP addresses isn’t going to work very well. You’ll want to have authentication and authorization, especially when your application is part of a larger multi-vendor cloud ecosystem for instance.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The particular use case I have in mind is for a OAI-PMH harvester service. There could be 1 OAI-PMH harvester servicing many Koha instances. It could be running in its own local Docker container or its own local virtual machine or even as a remote Internet service controlled by a different organisation. It’s only relation to Koha is in terms of accepting JSON serialized harvesting requests and sending MARCXML records for Koha to import. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For integrating the services, we could use point-to-point (P2P) communication via the HTTP APIs. That’s pretty much the only option we have at the moment. However, Koha will be adding RabbitMQ as a Message Broker (for a hub-and-spoke model), so Koha and the other services could have their own credentials to authenticate against the Message Broker, and use it for communication. Both models have their pros and cons. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>My current plan is to use <a href="https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26170">https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26170</a> to provide more stable Koha users and <a href="https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25905">https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25905</a> to provide an OAI-PMH ingestion endpoint to Koha. Then I’ll implement the OAI-PMH harvester separate from Koha (with a Koha plugin initially to send OAI-PMH harvesting requests to the OAI-PMH harvester service), which sends downloaded records to the Koha API for the Koha that requested the harvest. This approach will have some friction though. I’ll have to add a Koha user, share the Koha user credentials to the OAI-PMH service, register the Koha instance in the OAI-PMH service, and share the OAI-PMH credentials with Koha. That process could be unnecessary using a Message Broker. Another option would be to set up single sign on (SSO) with P2P where Koha and the OAI-PMH service delegate AuthN (and even potentially AuthZ) to an identity provider. That would make things smoother but also more complicated. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>If I wanted to more tightly integrate with Koha, I suppose I could create a koha-oaipmh CLI tool which automates the user creation and credential sharing I suppose. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The other benefit of using the Message Broker is that you don’t have to manage IP addresses and ports. I should look at the koha-sip tool again, but I don’t know how it handles setting up different ports for each different Koha instance. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In any case, I’m keen to get input from others on system design. On one hand, I’d like something that easily works for everyone, and on the other hand I’d like something that works really well. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>David Cook<o:p></o:p></p><p class=MsoNormal>Systems Librarian<o:p></o:p></p><p class=MsoNormal>Prosentient Systems<o:p></o:p></p><p class=MsoNormal>72/330 Wattle St<o:p></o:p></p><p class=MsoNormal>Ultimo, NSW 2007<o:p></o:p></p><p class=MsoNormal>Australia<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Office: 02 9212 0899<o:p></o:p></p><p class=MsoNormal>Online: 02 8005 0595<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US>From:</span></b><span lang=EN-US> Michael Hafen (TECH) <michael.hafen@washk12.org> <br><b>Sent:</b> Saturday, 8 August 2020 2:46 AM<br><b>To:</b> David Cook <dcook@prosentient.com.au><br><b>Cc:</b> Koha Devel <koha-devel@lists.koha-community.org>; Kyle Hall <kyle@bywatersolutions.com>; Tomas Cohen Arazi <tomascohen@theke.io><br><b>Subject:</b> Re: [Koha-devel] Best practices for using Koha APIs server-side by Koha<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>Maybe I'm lacking in imagination, but I can only think of two cases where a Koha to Koha api would be useful: scheduled tasks (cron, et. all), and command line scripts. I think in both of these cases it's feasible to avoid auth entirely since it is basically jumping right into Koha at the control level (assuming an MCV approach). As someone who has a deployment of Koha heavily dependent on IndependentBranches mode, I find I have to watch for %userenv{branch}, but that's for rare cases in which branch can't be taken from the data being operated on. The only other thing I can think of would be something like notices wanting to take a user's preferred language, and pull a language specific template (do we even do that at this point?).<o:p></o:p></p></div><div><p class=MsoNormal>Please enlighten me on your use cases, I'm probably missing something.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Fri, Aug 7, 2020 at 5:09 AM <<a href="mailto:dcook@prosentient.com.au">dcook@prosentient.com.au</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hi all,<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I mostly see Koha APIs being used client-side by Koha using cookie authentication.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I know we have OAuth2 and Basic Auth that can be tied to a Koha user, and used by a third-party system, which is great.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>However, what about when we have server-side Koha components that want to use Koha APIs? (I suppose you could set up a user for that component, but it could always be deleted by an overzealous librarian.)<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Or should we only be using a Message Broker (like RabbitMQ) for passing messages among Koha server-side components? (That would require more of a service oriented architecture of course, which we don’t have in place, while we do have a HTTP API in place.)<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>What are your thoughts?<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>David Cook<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Systems Librarian<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Prosentient Systems<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>72/330 Wattle St<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Ultimo, NSW 2007<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Australia<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Office: 02 9212 0899<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Online: 02 8005 0595<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div><p class=MsoNormal>_______________________________________________<br>Koha-devel mailing list<br><a href="mailto:Koha-devel@lists.koha-community.org" target="_blank">Koha-devel@lists.koha-community.org</a><br><a href="https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" target="_blank">https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>website : <a href="http://www.koha-community.org/" target="_blank">http://www.koha-community.org/</a><br>git : <a href="http://git.koha-community.org/" target="_blank">http://git.koha-community.org/</a><br>bugs : <a href="http://bugs.koha-community.org/" target="_blank">http://bugs.koha-community.org/</a><o:p></o:p></p></blockquote></div><p class=MsoNormal><br clear=all><br>-- <o:p></o:p></p><div><div><div><div><div><div><p class=MsoNormal>Michael Hafen<o:p></o:p></p></div><p class=MsoNormal>Washington County School District Technology Department<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>Systems Analyst<o:p></o:p></p></div></div></div></div></div></body></html>