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?).

Please enlighten me on your use cases, I'm probably missing something.

On Fri, Aug 7, 2020 at 5:09 AM <dcook@prosentient.com.au> wrote:

Hi all,

I mostly see Koha APIs being used client-side by Koha using cookie authentication.

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.

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.)

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.)

What are your thoughts?

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/