FOLIO: Use shib_cql if Shib is used for login

[dltj]

Fixes VUFIND-1615.

[demiankatz]

Thanks, @dltj! I've somehow managed to have three different thoughts related to the same if statement -- see below.

Beyond that, I guess the main question is whether this is too specific of a customization for the core distribution. I definitely see the use case, but it relies on a specific combination of authentication and ILS technology which may or may not be commonly found. I'm definitely not automatically opposed to merging this, but that's a factor to consider.

Perhaps a good first step would be to refactor the code so there's a protected function getLoginCQL that returns the login CQL statement, since this would make it easier to implement these types of customizations in future, whether or not we decide to adopt this one now.

What do you think?

[demiankatz]

The Shibboleth session ID is configurable here: https://github.com/vufind-org/vufind/blob/dev/config/vufind/config.ini#L835 -- I wonder if it's worth making config.ini available to the FOLIO driver so it can check for this configuration (or if it's at least worth adding a setting to Folio.ini to allow override of the name of the parameter).

We also try to avoid directly referencing $_SERVER in our code, since Laminas wraps this up in the request object. However, that raises the question of whether it's worth creating a new dependency on the request object for this one feature. Something to think about, at least.

And just as a matter of style, I think isset($this->config['User']['shib_cql']) might be more typical of VuFind style than using array_key_exists.

[dltj]

The Shibboleth session ID is configurable here: https://github.com/vufind-org/vufind/blob/dev/config/vufind/config.ini#L835 -- I wonder if it's worth making config.ini available to the FOLIO driver so it can check for this configuration (or if it's at least worth adding a setting to Folio.ini to allow override of the name of the parameter).

Ah, good point...I thought I had seen that value somewhere. If you can point me in the right direction to "make config.ini available to the FOLIO driver" I'm happy to add that. I'll push a change for the isset() versus array_key_exists()...this is my lack of PHP experience showing through...I don't know the common idioms; I just know I need something done and I go looking for the language-specific way of doing it.

[demiankatz]

The easiest way to make the setting available to the FOLIO driver is through the factory... so in FolioFactory.php, you can add something like:

$config = $container->get(\VuFind\Config\PluginManager::class)->get('config');

and then $config will be an object representation of config.ini that you can either pass directly into the Folio constructor, provide via a setter, etc. The best approach to getting the data into the driver is probably a matter of taste. :-)

And no worries about the isset/array_key_exists thing. In PHP, the general rule is that if you can do something with either a function or a built-in keyword, the keyword approach is usually faster and more concise. But of course that requires you to know all the options available to you. :-)

[demiankatz]

I also notice that there were two array_key_exists calls here, but only one has been changed to isset. Though perhaps you're holding off on changing the other one since other parts of our discussion may impact the same line of code. :-)

[dltj]

Beyond that, I guess the main question is whether this is too specific of a customization for the core distribution. I definitely see the use case, but it relies on a specific combination of authentication and ILS technology which may or may not be commonly found. I'm definitely not automatically opposed to merging this, but that's a factor to consider.

I can't speak to the other VuFind drivers, but FOLIO's use of CQL and the customizable capabilities it brings to connecting VuFind to the ILS are quite useful. I know, at least in the NCIP space, it is quite difficult to use combinations of matching identifiers (with one unnamed system allowing for only barcode to be used). This might be a bit of an edge case on one specific driver—and the work-around is not all that hard—but I thought it useful to add it here so someone else doesn't need to work out something equivalent.

Perhaps a good first step would be to refactor the code so there's a protected function getLoginCQL that returns the login CQL statement, since this would make it easier to implement these types of customizations in future, whether or not we decide to adopt this one now.

Ah, now that is a level of abstraction I'm not feeling qualified to comment on. Related to your question above, I'm trying to imagine other combinations of ChoiceAuth authentication selections other than "Shibboleth-ILS" where this would be useful. Maybe it is just that I haven't used the other options.

[demiankatz]

I guess what I'm thinking about here is that this customization is specialized for two different reasons: first of all, it behaves differently depending on the authentication method, and secondly, it refers to implementation details of a specific authentication method. Ideally, I'd love to set things up so that we could achieve both of these things in a more generic way, so that this behavior is one possible configuration, but more things are also possible.

One possible improvement could be to fetch the \VuFind\Authentication\Manager service out of the container and use it to determine the active authentication method so we don't have to "sniff" for Shibboleth at all.

I also wonder if there's some advantage to be gained from refactoring code that extracts attributes from authentication methods so that we could fetch those attributes from the authentication manager and use them in situations like this. There are at least two other authentication methods beyond Shibboleth (LDAP and CAS) that can provide user attributes that could be useful in situations like this, so having a generic way to obtain them without caring about the authentication implementation details would be valuable. But I think that's a trickier problem to solve since in different scenarios, the access to the attributes may be more limited, so we might need to cache them in the session or database to ensure that we have them when we need them. I can give this some deeper thought if you think it's a road potentially worth following!

[demiankatz]

@dltj, I just noticed that this PR hasn't gone anywhere in quite a while, so I thought I'd follow up and see if this is something you still want to pursue. I'm happy to collaborate as needed -- just checking if this is something we need to revive, or if it is no longer needed.