Jeg fikk endelig i dag til runtest-kjøring mot vår testinstans, med global keycloak og PostgreSQL. Startet ny gren basert på 442e403d6f755b2cac0dad21e33c404ad1e494ae og hentet inn JWT-endringen (6fa5481e65a417db2122f6fb143b1edab426d9b0) i dene testgrenen. Med denne endringen på plass ga runtest en ny feilmelding ved forsøk på oppretting, som Thomas på IRC mente kom av at min keycloak-bruker ikke var registrert i Nikita. Det viste seg å stemme, da runtest begynte å virke etter at jeg endret navn på brukeren med brukernavn 'recordkeeper@example.com' til mitt brukernavn i Keycloak.
For å unngå å måtte endre brukernavn på eksisterende brukere, men heller opprette ny bruker direkte i databasen for å komme igang, så laget jeg følgende sh-skript som bruker psql for å opprette en bruker. Har ikke fått testet disse brukerene ennå, men regner med at de vil fungere.
Jeg har kalt programmet nikita-user-create-psql og kjører det slik:
./nikita-user-create-psql brukernavn Fornavn Etternavn
Jeg tenker det er aktuelt for første bruker for å få tilgang til API (vår keycloak har ingen bruker 'admin@example.com' og 'recordkeeper@example.com') og at øvrige brukere kan opprettes med API-endepunktet ny-bruker.
Jeg tenker forvalgt oppsett for Nikita bør være uten testbrukere, og at oppretting av første bruker bør dokumenteres i stedet for å bruke 'admin@example.com'.
Her er koden så langt:
#!/bin/sh # Author: Petter Reinholdtsen # License: GPL v2 or later at your choice
PGHOST=postgresql-host.example.com PGUSER=nikita_noark5_user PGDB=nikita_noark5_db
USERNAME="$1" FIRSTNAME="$2" LASTNAME="$3" if [ -z "$4" ]; then ORG="Organisation" else ORG="$4" fi if [ -z "$5" ]; then ROLE="RECORDS_MANAGER" fi
USERUUID="$(uuidgen)"
psql --port 5432 --host $PGHOST --user $PGUSER $PGDB -c " BEGIN TRANSACTION; INSERT INTO system_id_entity( system_id, created_date, last_modified_date, created_by, owned_by, version, dtype ) VALUES ( '$USERUUID', NOW(), NOW(), 'system', null, 0, 'User' );
INSERT INTO ad_user( system_id, username, firstname, lastname, account_non_expired, credentials_non_expired, account_non_locked, enabled, user_organisation_id ) VALUES ( '$USERUUID', '$USERNAME', '$FIRSTNAME', '$LASTNAME', true, true, true, true, (SELECT system_id FROM ad_organisation WHERE organisation_name = '$ORG') );
--INSERT INTO ad_user_authority( -- authority_id, -- f_pk_user_id --) VALUES ( -- (SELECT id FROM ad_authority WHERE authority_name = '$ROLE'), -- '$USERUUID' --); END TRANSACTION; "
Det slår meg forresten at tre av de fire bool-flaggene (account_non_expired, credentials_non_expired, account_non_locked) burde være tidspunkt for da flagget ble gyldig i stedet for sann/usann, for å kunne se når en konto gikk ut på dato, ble låst og passordet utløp.