Kramerius 5 - nekonzistentní výsledky z API /v5.0/user

[dzatloukal]

Dobrý den, máme problém s voláním kramerius API /v5.0/user.

Po přihlášení do DNNT přes Shibboleth dochází k nekonzistentům výsledkům při volání Kramerius API pro získání informací o uživateli - search/api/v5.0/user

Ihned po úúspěšné autentikaci dojde k dotazu na API search/api/v5.0/user s nastaveným JSESSIONID, API však vrací "Not Logged" objekt viz níže.:

{lname: "not_logged", firstname: "not_logged", surname: "not_logged", session: {},…}
firstname: "not_logged"
id: -1
lname: "not_logged"
roles: [{name: "common_users", id: 1}]
session: {}
surname: "not_logged"

O chvilku později však stejný dotaz se stejnými parametry (stejné JSESSIONID, stejné _shibsession) vrací korektní informace o uživateli.

Důsledkem tohoto se po přihlášení na stránce informace o uživateli nezobrazují a je nutný udělat refresh stránky, po kterém se request na API pošle znovu, aby se informace korektně zobrazily

Jedná se o DNNT konkrétně lištu s vypsaným uživatelem.

Stav po přihlášení a korektní autentikaci:

Stav po refreshi stránky:

Mohl bych poprosit o prověření, případně o informaci, jak se informace ohledně uživatele z API /uuser dostávájí a proč ihned po autentikaci vrací "not logged" objekt?

[pavel-stastny]

Šlo by vysledovat, zda letí na Krameria všechny hlavičky ze SP během těch dvou dotazů ?

[dzatloukal]

Nevím přesně co znamená všechny hlavičky, ale porovnal jsem oba dotazy na síťové vrstvě a posílají se úplně stejné hodnoty, nic nepřebývá ani nic nechybí.

[jahhoo]

@pavel-stastny Prosím o reakci. V NK je to pro provozování DNNT důležité.

[pavel-stastny]

@jahhoo Nedaří se mi to u sebe reprodukovat. Šlo by zapnout logování hlaviček dotazu na úrovni tomcatu ? To by mi pomohlo. (Hlavičky posíláné z service provideru do tomcatu)

[dzatloukal]

@pavel-stastny na úrovni tomcatu jsem se snažil zapnout logování requestů a response dle https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Request_Dumper_Filter ale vypadá to, že se neloguje do souboru vše, protože tam vidím requesty pouze na zoomify ale už ne requesty např. na kramerius api. Můžete mi poradit, kde lze logování všech dotazů zapnout?

[pavel-stastny]

@dzatloukal Opss.. S request dumperem neporadím ale ono by stačilo zapnout pouze ty hlavičky, které jsou v hlídané v shibrules.txt a ty pak dopropagovat do access logu. A na to by mělo stačit obohatit pattern pro logování v AccessValve. Něco na způsob affilation:%{affilation}i eppn:%{eppn}i eduPersonUniqueId:%{eduPersonUniqueId}i cn:%{cn}i sn:%{sn}i (Pro hlavičky: affilation, eppn, eduPersonUniqueID, cn a sn)

[dzatloukal]

@pavel-stastny díky za tip, přidal jsem tyto hodnoty do AccessValve, do logu se vypisují. Porovnal jsem, co se posílá po přihlášení a po refreshi a v obou případech se posílá vyplněné jen eppn. Affilation, eduPersonUniqueId, cn a sn jsou prázdné.

[pavel-stastny]

@dzatloukal Ok. Zkusim to u sebe nejak nasimulovat.

[dzatloukal]

@pavel-stastny povedlo se něco zjistit? Co všechno musí letět z IdP do Shibbolethu, aby se tyto údaje o uživateli v krameriovi zobrazily?

[pavel-stastny]

@dzatloukal Bohužel nepodařilo. Ad atributy z Idp. Záleží na tom, co je definováno shibrules.txt. Ten mapuje shib uživatele na role v krameriovi na základě attributů z Idp.

[pavelkocourek]

Viz #774 : Nelze reprodukovat. Lze zavřít ?
Případně je potřeba, abyste obecně popsali čeho chcete dosáhnout

[JanMeritus]

@jahhoo poprosim o odpoved

[dzatloukal]

Je možno uzavřít. Problém byl nakonec vyřešen přidání rewrite rule do httpd configu tak, aby se api /v5.0/user provolalo znovu a dostali jsme potřebný výsledek.

[zabak]

@dzatloukal @JanMeritus jaký je vlastně use-case? Kdy se to api takto využívá?

[pavel-stastny]

@zabak Já jsem to pochopil tak, že se jim shibboleth uživatel po přihlášení nejevil jako přihlášený. (v klientovi). Jevil se přihlášený až po reloadu. Nicméně já nedokážu toto chování u sebe reprodukovat. V MZK jste takový problém pozorovali ?