Chybné datum konce registrace KNAV

[jandera]

V "Moje knihovny" se u KNAV zobrazuje "Konec platnosti registrace:" z globální knihovny z305-sub-library=KNA50 pole z305-expiry-date, ale v našem případě je validní datum expirace z dílčí knihovny KNAV, tedy z305-sub-library=KNAV pole je stejné z305-expiry-date

[PetraZabickova]

Komunikace s Alephem je na portále řešená pomocí Aleph RESTful API. Informace o platnosti registrace se zjištuje pomocí volání /patronStatus/registration a přichází v položce . Jinou hodnotu nez tu, kterou zobrazujeme nemame.

Divali jsme se ve vasem lokalnim vufindu se to zobrazujete jinak. Jedine co nas napada je, ze to mate implementovane pomocí X-serveru nebo pridavate do toho restoveho volani nejaky pro nas zcela neznamy parametr.

Případně nejste schopni v Alephu ovlivnit hodnotu pro restovem api?

[jandera]

Jak jsem na to koukal, tak ono se to dá volat jen pomocí X-Services a ještě se znalostí hesla: "http://server.name:8991/X?op=bor-auth&library=usm50&bor_id=00000012&verification=00000012&sub_library=HIL" u nás to kolegové nízkoúrovňově tahají přímo ze Z305 a ukládají jako jeden z parametrů do LDAP odkud to pak natahujeme do VuFindu. Bohužel asi nebude cesta jak to dostat na knihovny.cz, ale zeptám se našeho IT.

[mduda100871]

Zdravím,

jako nejčistší řešení se mi jeví to, že datum expirace začneme uvolňovat z našeho IdP jako jeden z atributů. Stejným způsobem už uvolňujeme pro CPK alephID.

MD

[PetraZabickova]

Dobrý den,

uvolnovanim tohoto udaje v atributu IDP by to resilo situaci jen v pripade, ze by se uzivatele vzdy hlasili uctem KNAV. Pokud by si propojili identity a hlasili se jinou identitou, tak bychom tuto informaci nedostali.

Zdravi, PZ

[mduda100871]

V tom případě žádné další řešení bohužel nemám.

MD

[mduda100871]

V tom případě žádné další řešení bohužel nemám.

MD

Resp. rychlé řešení nemám, museli bychom na naší straně implementovat/naprogramovat nějaký endpoint, který by na základě nějakého jednoznačného identifikátoru uživatele provedl dotaz buď do LDAP serveru nebo Oraclu pod Alephem a vrátil datum expirace.

MD

[jiripavlik88]

Nepůjde řešit stejně jako u Alephu v MZK?

[mduda100871]

Jak konkrétně?

[jiripavlik88]

Jak na to bude vědět @PetraZabickova . Datum expirace účtu v MZK se mi v cpk-front.mzk.cz zobrazuje správně.

[mduda100871]

MZK má přístup na naše API Alephu, problém ale je, že k podrobnějším informacím o uživateli je potřeba při voláni API znát uživatelovo heslo v Alephu...

[PetraZabickova]

Petra Žabičková tohle bohužel nevyřeší @jiripavlik88 . Jak jsme již psali výše, díky složitější hierarchické konfiguraci ústřední knihovny a jednotlivých ústavů, by bylo potřeba řešit pomocí X services. V Aleph RESTful APi, ktere je implementovane na portalu, tato informace neni.

[mduda100871]

Nemám oprávnění sám rozhodnout o plném zpřístupnění X serveru, nicméně si myslím, že ten problém to stejně neřeší, pokud by druhá strana neznala zároveň heslo k tomu konkrétnímu účtu - jak psal výše @jandera.

A pokud bychom nějakým způsobem hesla uživatelů chtěli zpřístupňovat třetí straně, tak si myslím, že to je hodně citlivé, skoro si myslím, že neprůchodné.

Tady v této chvíli k tomu asi nejsem schopen více diskutovat, kolega @jandera by to měl možná delegovat na naše správce Alephu.

MD

[jiripavlik88]

U Národní knihovny získáte datum expirace účtu čtenáře také v RESTovém API, @PetraZabickova ?

[jandera]

Bohužel i u nás lokálně jsme to právě vyřešili tím natažením do LDAP přímo ze Z305, u nás globální sublibrary KNA50 obsahuje nerelevantní datum, které je nastaveno na 70 let. Správné datum je až v dílčí sublibrary, v našem případě KNAV (a pak u dalších knihoven AV ČR v jejich dílčích knihovnách).

Pokud by to šlo, tak by bylo kompromisní řešení datum expirace v KNAV ukazovat pouze při přihlášení přes naše IdP a pokud bude mít uživatel poslučované identity a přihlásí se jinou tak nezobrazovat nic.

[mduda100871]

S tím, že až u nás proběhne (snad letos) upgrade Alephu na 23, tak se můžeme případně zamyslet na nějakým speciálním endpointem, kde pak můžeme externím subjektům "propagovat" vybrané údaje z uživatelských účtů bez potřeby trápit se s implementaci REST-API nebo X serveru v Alephu, což je tak trochu peklo popravdě.

MD

[xrosecky]

@mduda100871 Heslo přihlášeného uživatele pro volání X serveru nepotřebujeme, stačí systémový účet s omezením jen na volání služby bor_info + případně limit na naše IP adresy. Otázka je ale, zda službu bor_info lze donutit, aby vrátila správný datum platnosti registrace - museli bychom vyzkoušet.

[mduda100871]

Jak jsem psal výše, o zpřístupnění X serveru nerozhodnu, je to dost citlivé - zřejmě by to muselo být podloženo nějakou smlouvou, nevím.

Tady poprosím kolegu @jandera, aby do toho zapojil naše správce Alephu.

Můj návrh řešení jsem popsal výše, teď se musí někdo rozhodnout, kterou cestu zkusíme. Cesta prostřednictvím X serveru je v tomto případě asi rychlejší - pokud lze tímto způsobem vytahovat data z dílčích knihoven jak píše @xrosecky výše. To také netuším.

[jandera]

Kolegům od Alephu jsem to teď poslal. Jinak mně se to přes bor_info nepodařilo, vrací to datum z KNA50. Jak jsem psal výše, relevantní datum dostanu jen přes bor-auth a to ještě se znalostí hesla. Tam je pak v sekci Z305 relevatní sublibrary např.: z305-sub-library>KNAV</z305-sub-library z305-open-date>16/12/2019</z305-open-date z305-update-date>04/02/2022</z305-update-date z305-bor-type z305-bor-status>User</z305-bor-status z305-registration-date>00000000</z305-registration-date z305-expiry-date>04/11/2022/z305-expiry-date

[PetraZabickova]

Vzhledem k neaktivitě toto issue zavírám. Pokud by došlo k nějaké změně na straně KNAV, prosím dejte nám vědět a mi se problémem budeme znovu zabývat.