Unable to retrieve objects with IP restrictions when using Aleph authentication

• Article Type: General
• Product: DigiTool
• Product Version: 3

Description:
One of our collections is restricted to logged in users.
These objects also contain access metadata (ip restriction).
When I am logged in via PDS by using our Aleph X server authentication (the related configuration file is aleph_16.pl), and I am within the IP range, I get the following error message: "Failed to run access rights check".

Resolution:
This is the case due to interactions with other EXL products.
The id (or bor-id) field is not needed in bor-info responses for other EXL products and it is enough that it get passed only once for authentication purposes.

DigiTool AR checks, however, needs the id in bor-info.
The id was not passed by ALEPH to bor-info - therefore, when DigiTool access rights check looked for the id, it was not there - even though it is passed to the database in z312 as z312-source-id properly.

Here is the change made to enable proper AR checks in DigiTool in the pds setup:

in tab_service.loc
Commented out this line in BOR-INFO section:
!params = library.science.edu,443,BOR_AUTHENTICATE,LOC50,Y,WWW-X,WWW-X

And defined this instead:
params = library.science.edu,443,BOR_INFO&TRANSLATE=N&loan-option=N&hold-option=N&cash-opt
ion=N,LOC50,Y,WWW-X,WWW-X

Notice we use bor_info instead of bor_authenticate - to ensure we get the id field.
We also use loan, hold and cash-opt options set to NO.
This ensures that lots of information from ALEPH related to those areas are not passed to DigiTool as it is unnecessary and could slow down the authentication process.
Also, we added a translate = n which ensures that the data is passed as is and is not normalized as it is by default on the ALEPH
side, for instance, by default dates are passed from ALEPH normalized 01/01/2006, however this input is going to
the database, so we want it as it exists in the ALEPH db (like in DigiTool) 20060101.
The translate = n is not mandatory, but as long as we were at it, it ensures data that will enter our db.

Also if you run into the same problem When using LDAP, mapping username to id in the ldap_institute.conf will solve the problem.