Our little library is preparing to use the Kanopy video streaming service. Kanopy can use SIP2 to query our Koha server for the purpose of user authentication. That's great; I can enable SIP2 pretty easily. The problem is that our librarian wants to put limits on which patrons can use Kanopy. The idea is that we don't want to allow more than one person per household to be able stream videos; otherwise mom, pop, and all the kids could go crazy one weekend on a Buffy The Vampire Slayer binge, for example. But Kanopy and Koha don't have a way to impose this kind of limit. So I came up with the following idea, which does seem to work in my test VM: 1. Add a new patron attribute called "KANOPY_OK", which has a yes/no value. Set it to yes for those patrons that will be allowed access to Kanopy. 2. Hack the SIP server code for "handle patron status" to check the incoming client's IP address against a Kanopy-provided list of IP addresses. If there is a match, authenticate the patron only if their "KANOPY_OK" atribute is "yes" (actually "1"). But I hate the fact that I had to hack Koha to do this (see part of the hack below). Am I'm going at this the wrong way? Would it make more sense to enhance the plugin architecture to add a SIP2 patron filter function like the one below? Is this just too ugly to ever be considered seriously? Thanks in advance, Mark P.S. Here's the main part of the hack, which is a function that is called from handle_patron_status and handle_patron_info. my @kanopy_ips = ( "208.66.24.46", "104.239.197.182", "18.209.148.51", "34.232.89.121", "34.234.81.211", "34.235.227.70", "34.235.53.173", "52.203.108.44" ); sub sip2_check_patron { my ( $patron, $server ) = @_; if ( $patron ) { my $ipaddr = $server->{server}->{client}->peerhost; foreach my $kanopy ( @kanopy_ips ) { if ( $ipaddr =~ /^(::ffff:)?\Q$kanopy\E$/ ) { my $borrowernumber = $patron->{borrowernumber}; my $value = C4::Members::Attributes::GetBorrowerAttributeValue( $borrowernumber, 'KANOPY_OK' $ return $value eq "1"; } } } return 1; }
Hi Mark, reading your use case made me think of some open bugs we have, the first being maybe a similar use case to yours: *Bug 16694* <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16694> - Limit SIP2 auth by patron attribute *Bug 10077* <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10077> - Pass extended patron attributes via Borrower SIP protocol Hope this helps, Katrin On 12.10.2018 19:46, Mark Alexander wrote:
Our little library is preparing to use the Kanopy video streaming service. Kanopy can use SIP2 to query our Koha server for the purpose of user authentication. That's great; I can enable SIP2 pretty easily.
The problem is that our librarian wants to put limits on which patrons can use Kanopy. The idea is that we don't want to allow more than one person per household to be able stream videos; otherwise mom, pop, and all the kids could go crazy one weekend on a Buffy The Vampire Slayer binge, for example.
But Kanopy and Koha don't have a way to impose this kind of limit. So I came up with the following idea, which does seem to work in my test VM:
1. Add a new patron attribute called "KANOPY_OK", which has a yes/no value. Set it to yes for those patrons that will be allowed access to Kanopy.
2. Hack the SIP server code for "handle patron status" to check the incoming client's IP address against a Kanopy-provided list of IP addresses. If there is a match, authenticate the patron only if their "KANOPY_OK" atribute is "yes" (actually "1").
But I hate the fact that I had to hack Koha to do this (see part of the hack below). Am I'm going at this the wrong way? Would it make more sense to enhance the plugin architecture to add a SIP2 patron filter function like the one below? Is this just too ugly to ever be considered seriously?
Thanks in advance, Mark
P.S. Here's the main part of the hack, which is a function that is called from handle_patron_status and handle_patron_info.
my @kanopy_ips = ( "208.66.24.46", "104.239.197.182", "18.209.148.51", "34.232.89.121", "34.234.81.211", "34.235.227.70", "34.235.53.173", "52.203.108.44" );
sub sip2_check_patron { my ( $patron, $server ) = @_;
if ( $patron ) { my $ipaddr = $server->{server}->{client}->peerhost; foreach my $kanopy ( @kanopy_ips ) { if ( $ipaddr =~ /^(::ffff:)?\Q$kanopy\E$/ ) { my $borrowernumber = $patron->{borrowernumber}; my $value = C4::Members::Attributes::GetBorrowerAttributeValue( $borrowernumber, 'KANOPY_OK' $ return $value eq "1"; } } } return 1; } _______________________________________________ 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/
Excerpts from Katrin Fischer's message of 2018-10-14 12:02:44 +0200:
reading your use case made me think of some open bugs we have, the first being maybe a similar use case to yours:
*Bug 16694* <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16694> - Limit SIP2 auth by patron attribute
Thank you for that! It's very similar, except that our use case is more complicated than I said. It turns out our library has to deal with two different services in the SIP2 code. One service is Kanopy, as I mentioned; the other is a consortium connected to Overdrive that provides ebooks and audio books. Each service has to be handled slightly differently, perhaps using a separate patron attribute for each. We need to find out which service is performing the SIP2 request by examining the client IP address. In the bug mentioned above, Marcel suggested putting the validation code in Patron.pm. But our very site-specific complications led me to think of putting the validation code into a plugin.
Hi Mark, just wondering, reading this again - Are you not using separate entries with different logins for the different services? Katrin On 14.10.18 15:12, Mark Alexander wrote:
Excerpts from Katrin Fischer's message of 2018-10-14 12:02:44 +0200:
reading your use case made me think of some open bugs we have, the first being maybe a similar use case to yours:
*Bug 16694* <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16694> - Limit SIP2 auth by patron attribute Thank you for that! It's very similar, except that our use case is more complicated than I said.
It turns out our library has to deal with two different services in the SIP2 code. One service is Kanopy, as I mentioned; the other is a consortium connected to Overdrive that provides ebooks and audio books. Each service has to be handled slightly differently, perhaps using a separate patron attribute for each. We need to find out which service is performing the SIP2 request by examining the client IP address.
In the bug mentioned above, Marcel suggested putting the validation code in Patron.pm. But our very site-specific complications led me to think of putting the validation code into a plugin. _______________________________________________ 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/
Excerpts from Katrin Fischer's message of 2018-10-27 17:27:23 +0200:
just wondering, reading this again - Are you not using separate entries with different logins for the different services?
That is the intent. I didn't think of this until just now, but it looks like I can use the different logins to distinguish between the services. Thanks for the hint!
Glad it was helpful :) On 27.10.18 17:35, Mark Alexander wrote:
Excerpts from Katrin Fischer's message of 2018-10-27 17:27:23 +0200:
just wondering, reading this again - Are you not using separate entries with different logins for the different services? That is the intent. I didn't think of this until just now, but it looks like I can use the different logins to distinguish between the services. Thanks for the hint!
participants (2)
-
Katrin Fischer -
Mark Alexander