Lad lånerne logge ind som deres bibliotek understøtter, oprette sig som nye lånere, dele en enhed og komme ind igen når de har glemt adgangskoden.

4 af 4 understøttet 16. oktober 2026

2.2.1 Log ind

Understøttet

Lad låneren identificere sig, så klienten kan vise lån, reservationer og alt andet der hører til låneren.

Det kan du bygge

Login med de metoder bibliotekssystemet tilbyder: identifikator og adgangskode eller pinkode, identifikator alene, eller single sign-on gennem en identitetsudbyder. Konfigurationen fortæller klienten hvilke metoder og identifikatortyper den skal tilbyde, så loginskærmen passer til biblioteket.

Typisk flow

  1. Med adgangskode eller pinkode sender klienten identifikator og kode til AuthenticatePatron.
  2. Uden kode sender klienten identifikatoren alene til AuthenticatePatronNoPassword.
  3. Med single sign-on henter klienten login-URL'en med GetPatronAuthenticationUrl, og låneren logger ind hos identitetsudbyderen.
  4. Provideren returnerer code og state til CallbackPatron, og klienten veksler koden med AuthenticatePatronByCodeAndCodeVerifier.
  5. Alle metoder svarer med låneren, inklusive det patronId de øvrige kald om låneren bruger.

Det leverer API'et

  • patron.login i GetConfiguration angiver de identifierTypes, credentials og identityProviders provideren tager imod.
  • patron.login.credentials fortæller om låneren logger ind med password eller pin. Feltet i forespørgslen hedder password i begge tilfælde.
  • AuthenticatePatronNoPassword er kun tilgængelig når patron.login.allowWithoutCredential er true. Specifikationen siger at den kun bør bruges når det er absolut nødvendigt.
  • Single sign-on bruger PKCE: klienten sender en code_challenge og en state og senere den tilhørende code_verifier.
  • Findes låneren ikke, men kan oprettes, har callbacket can_be_registered=true, og klienten fortsætter med oprettelse (2.2.3).
  • Et mislykket single sign-on returnerer error på callbacket, for eksempel sso_login_cancelled eller provider_patron_not_found. Ved sso_access_denied og sso_consent_denied bør låneren henvises til sit bibliotek.

2.2.3 Opret låner

Understøttet

Lad en ny låner oprette sig hos biblioteket fra klienten.

Det kan du bygge

Lånerne bliver lånere uden at skulle på biblioteket: med en identifikator eller gennem en identitetsudbyder. De vælger hvor reservationer skal hentes, og accepterer bibliotekets samtykker som en del af oprettelsen.

Typisk flow

  1. Med en identifikator tjekker klienten med IsPatronRegistrationPossible at låneren kan oprettes.
  2. Låneren vælger et afhentningssted og accepterer samtykkerne. Klienten opretter låneren med RegisterPatronByIdentifier.
  3. Med single sign-on går låneren gennem identitetsudbyderen fra GetRegisterPatronUrl. Callbacket CallbackPatron har can_be_registered og de samtykker der skal accepteres.
  4. Er can_be_registered true, indsamler klienten afhentningssted og samtykker og opretter låneren med RegisterPatronByCodeAndCodeVerifier. Ellers har provideren allerede oprettet låneren, og klienten logger ind (2.2.1).
  5. Svaret fortæller i status hvor langt oprettelsen er nået.

Det leverer API'et

  • patron.registration i GetConfiguration angiver de identifikatortyper og identitetsudbydere der kan bruges til oprettelse.
  • status er done, in_progress eller contact_the_library. Er status done, bør patronId være sat; ellers logger låneren ind igen.
  • pickupLocation er påkrævet på begge oprettelseskald.
  • Klienten skal sikre at låneren har accepteret hvert samtykke i consents før forespørgslen sendes.
  • Samtykker fra callbacket har formen type:version, URL Base64-kodet, og alle skal med i oprettelsen.

2.2.4 Flere brugere

Understøttet

Lad flere lånere være logget ind på samme enhed og skifte mellem dem.

Det kan du bygge

Nyttigt for en husstand der deler en enhed: hver låner logger ind én gang, og klienten skifter mellem dem uden at logge ud og ind igen.

Typisk flow

  1. Hver låner logger ind for sig (2.2.1).
  2. Klienten gemmer patronId for hver låner der er logget ind på enheden.
  3. Når låneren skifter bruger, bruger klienten den valgte låners patronId i de kald der følger.

Det leverer API'et

  • Specifikationen har ingen særskilt operation for flere brugere. Skift af bruger sker i klienten.
  • At fjerne en låner fra enheden sker i klienten og ændrer ikke lånerens konto hos biblioteket.

Kald i API'et

API'et leverer dataene — din tjeneste udfører handlingen

2.2.5 Nulstil adgangskode

Understøttet

Lad en låner der har glemt sin adgangskode eller pinkode, få et link til at vælge en ny.

Det kan du bygge

Lånerne kommer selv ind på deres konto igen fra loginskærmen, uden at skulle kontakte biblioteket.

Typisk flow

  1. Låneren indtaster sin identifikator og den e-mailadresse biblioteket har registreret.
  2. Klienten kalder ResetPatronCredential.
  3. Provideren sender et nulstillingslink til adressen, og låneren vælger en ny kode gennem det.
  4. Låneren logger ind med den nye kode (2.2.1).

Det leverer API'et

  • Tilbyd kun funktionen når patron.credentials.resettable i GetConfiguration angiver en kode. Mangler credentials, tilbydes hverken nulstilling eller ændring.
  • credential vælger password eller pin. Mangler feltet, bestemmer provideren hvilken der nulstilles.
  • Identifikatoren følger patron.login.identifierTypes. email er påkrævet og vælger kun blandt lånerens adresser: linket sendes kun hvis adressen er knyttet til låneren og bekræftet.
  • En gyldig forespørgsel får altid 202, uanset om der sendes et link, så kaldet afslører aldrig om en låner findes.
  • Linket er providerens. Tokenet i det skal kunne bruges én gang og udløbe efter kort tid, og forespørgslen indeholder ingen URL.