Thanks for your feedback, Tomas! Apologies for my delay in responding.
I hadn’t thought about making it so that web users could configure providers… but that could be interesting. I think that’s a good point with the plugins. Even with the 3 providers with which I integrate, I notice implementation differences. Some of them legitimate and some illegitimate according to the OpenIDConnect specification. I really like the idea of refactoring and modularizing auth. I think maybe my patch actually shows that it shouldn’t be that hard to create hooks for authentication plugins. I’m swamped at the moment (like usual) but it would be fun/interesting to try… David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Tomas Cohen Arazi [mailto:tomasco...@gmail.com] Sent: Thursday, 18 October 2018 12:49 AM To: David Cook <dc...@prosentient.com.au> Cc: koha-devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Generic OpenIDConnect client David, it is nice to see your code submitted! I implemented a generic prototype too, based on the current code for Google's. At that point the doubts I had were about how to inject new routes for the callback. But that's solved the way we did in bug 21116. I didn't submit my prototype because: - I wasn't able to inject routes (yet) - A page for CRUD operations on OAuth providers needs to be implemented - An attribute mapping UI needs to be added for each OAuth provider - I had the feeling this should be done with plugins. Because every implementation has its details that make them less compatible with the other. This are my thoughts on the subject as well! El mié., 17 oct. 2018 a las 6:07, David Cook (<dc...@prosentient.com.au <mailto:dc...@prosentient.com.au> >) escribió: Hi all, About 4 years ago, I wrote a generic OpenIDConnect client, and kept telling myself that I would upstream it but I never did… until now: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21586. I wrote it for 1 specific client, so it exists heavily in a set of “Prosentient” namespaces and some of the code is legacy from 3.14 and could be replaced by modern code (I’m looking at you Koha::Prosentient::Borrowers), but maybe people can try it out and give me some feedback to make it worthy of a sign off, or people can adapt it and I can give feedback. (I already have some things I would like to change. I think I overuse base64url… but it is essential when working with JWTs. I think I just got carried away with a substitution command once.) I know we already have the GoogleOpenIdConnect. I actually wrote this code before that code existed, but I don’t think my code would work for Google the way it is now. It would probably need some alterations. Anyway, I was sick of telling myself that I would upstream it one day, so I sat down and made a patch and now it’s shared. Cheers, David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://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/ -- Tomás Cohen Arazi Theke Solutions (http://theke.io <http://theke.io/> ) ✆ +54 9351 3513384 GPG: B2F3C15F
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://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/
