search

LIBCAS / BankID-Registrator

GNU General Public License v3.0
0 stars 0 forks source link

Kontrola zdali bankou ověřená osoba má účet v naší Aleph databázi #2

Closed TOA-Anakin closed 8 months ago

TOA-Anakin commented 9 months ago

Scénář:

Osoba se ověřila přes BankID a BankID do naší aplikace vrátilo údaje o ověřené osobě - tento balík dat zahrnuje mimo jiné:

Nyní tedy lze provést kontrolu zdali daná osoba již má v Alephu účet.

Řešení v Ostravě

V Ostravě to mají uděláno tak, že se hledá shoda v těchto 3 výše zmíněných údajích v jejich Aleph databázi. Ten dotaz, který posílají do jejich databáze zní takto:

Vrať mi políčka Z303_REC_KEY, Z303_LAST_NAME, Z303_FIRST_NAME, Z303_BIRTH_DATE, Z305_REC_KEY, Z305_BOR_STATUS, Z305_EXPIRY_DATE, Z308_REC_KEY pro takové záznamy pro které současně platí tato kritéria:

  • Pole Z303_REC_KEY obsahuje prvních 12 znaků z pole Z305_REC_KEY
  • Pole Z305_REC_KEY je identické s Z308_ID
  • Pole Z303_BIRTH_DATE obsahuje datum narození poskytnuté od BankId
  • Pole Z303_LAST_NAME obsahuje příjmení poskytnuté od BankId
  • Pole Z303_FIRST_NAME obsahuje jméno poskytnuté od BankId
  • Pole Z308_REC_KEY obsahuje hodnotu začínající textem 01, což má být nějaké číselné označení typu přihlášení u nich v Ostravě

Výše zmíněný dotaz u nich v Ostravě pravděpodobně vrátí takovýto záznam (tabulkou lze scrollovat horizontálně):

Z303_REC_KEY Z303_NAME Z303_LAST_NAME Z303_FIRST_NAME Z303_BIRTH_DATE Z305_REC_KEY Z305_BOR_STATUS Z305_EXPIRY_DATE Z308_REC_KEY
MSVK58607 Testovaci Junnie Testovaci Junnie 20011101 MSVK58607 MSVK 04 20250207 01MSVK58607 MSVK

Naše řešení

Kontrolu zdali u nás má osoba účet na základě těchto 3 kritérií můžeme udělat stejně jako v Ostravě. Naše situace se liší v několika bodech:

Když pozměním dotaz z Ostravy pro naši situaci, tak bude vypadat takto:

Vrať mi políčka Z303_REC_KEY, Z303_LAST_NAME, Z303_FIRST_NAME, Z303_BIRTH_DATE, Z305_REC_KEY, Z305_BOR_STATUS, Z305_EXPIRY_DATE, Z308_REC_KEY pro takové záznamy pro které současně platí tato kritéria:

  • Pole Z303_REC_KEY obsahuje prvních 12 znaků z pole Z305_REC_KEY
  • Pole Z305_REC_KEY je identické s Z308_ID
  • Pole Z303_BIRTH_DATE obsahuje datum narození poskytnuté od BankId
  • Pole Z303_NAME obsahuje příjmení a jméno (přesně v tomto pořadí), obojí poskytnuté od BankId
  • Pole Z308_REC_KEY obsahuje hodnotu začínající textem 00KNAV, což má být nějaké číselné označení typu přihlášení u nás

Tento náš dotaz pak vrátí např. toto (tabulkou lze scrollovat horizontálně):

Z303_REC_KEY Z303_NAME Z303_LAST_NAME Z303_FIRST_NAME Z303_BIRTH_DATE Z305_REC_KEY Z305_BOR_STATUS Z305_EXPIRY_DATE Z308_REC_KEY
KNAV58607 Testovaci Junnie 20011101 KNAV58607 KNAVP 04 20250207 00KNAV58607 KNA50
KNAV58607 Testovaci Junnie 20011101 KNAV58607 KNAV 04 20250207 00KNAV58607 KNA50
KNAV58607 Testovaci Junnie 20011101 KNAV58607 KNA50 04 20250809 00KNAV58607 KNA50
KNAV58607 Testovaci Junnie 20011101 KNAV58607 KNAVD 04 20250207 00KNAV58607 KNA50

ZÁVĚR

@jandera Jak vidíš, u nás to vrátí vícero záznamů, zdá se, že pro každou bázi jeden. Potřeboval bych tedy nějaké bližší info na toto téma.

jandera commented 9 months ago

@TOA-Anakin Ahoj, kontrolu na již existujícího uživatele máme vymyšlenou přes API. Využijeme pro to ID08 v ALEPHu. Bude to vyžadovat nějaké prerekvizity:

  1. Marek každému existujícímu uživateli přidá ID08 v syntaxi PRIJMENIJMENOYYYYMMDD
  2. Ty přidáš do registračního klienta https://github.com/Knihovna-AVCR-web/knav-client přidáš do obou lišt funkci, která bude ID08 vytvářet u ručně zakládaných registrací. V XML je to část Z308: ` I 08 TestovaciJunnie20011101 00 AC N

    `

Přidal jsem k tesovacímu čtenáři KNAV58607

A teď když na API pošlu XML, které má v ALEPHu shodné ID08, tak se mi vrátí z API jiná odpověď a uživatele to nezaloží:

image

V odpovědi API chybí na začátku několik řádků Succeeded to WRITE table

image

TOA-Anakin commented 9 months ago

@jandera

Chápu to tedy správně, že tuto kontrolu existence pole ID08 s hodnotou PrijmeniJmenoYYYYMMDD provádí Aleph automaticky při každém pokusu o vytvoření patrona?

Pokud ano, tak tedy v podstatě v této naší BankID-Registrator aplikaci budeme provádět kontrolu existence Aleph účtu tím, že se ho pokusíme založit za pomocí XML, které by mimo jiné obsahovalo:

...
<z308-key-type>08</z308-key-type>
<z308-key-data>PrijmeniJmenoYYYYMMDD</z308-key-data>
...

A Aleph API by nového patrona mělo či němělo vytvořit v závislosti na existenci záznamu obsahujícího pole ID08 s hodnotou PrijmeniJmenoYYYYMMDD.

Je to tak?

jandera commented 9 months ago

@jandera

Chápu to tedy správně, že tuto kontrolu existence pole ID08 s hodnotou PrijmeniJmenoYYYYMMDD provádí Aleph automaticky při každém pokusu o vytvoření patrona?

Pokud ano, tak tedy v podstatě v této naší BankID-Registrator aplikaci budeme provádět kontrolu existence Aleph účtu tím, že se ho pokusíme založit za pomocí XML, které by mimo jiné obsahovalo:

...
<z308-key-type>08</z308-key-type>
<z308-key-data>PrijmeniJmenoYYYYMMDD</z308-key-data>
...

A Aleph API by nového patrona mělo či němělo vytvořit v závislosti na existenci záznamu obsahujícího pole ID08 s hodnotou PrijmeniJmenoYYYYMMDD.

Je to tak?

@TOA-Anakin Ano, je to tak. My můžeme sestavit XML z údajů získaných od BankID, s novým ID, barcode, se záměrem založit nového patrona, ale pokud shodné ID08 v ALEPHu již bude, tak se nezaloží a vrátí to jinou odpověď. V tu chvíli budme vědět, že jde o prodlužování stávajícího patrona.

TOA-Anakin commented 9 months ago

Pro dokumentaci a budoucí generace 😀, zde odkaz na popis důvodu proč jsme se nakonec rozhodli použít přímý dotaz do Aleph Oracle databáze (podobně jak to mají v Ostravě ale sofistikovaněji) namísto původně zamýšleného Aleph API.