# Vern ein assistent med di eiga pålogging via callbackUrl

`callbackUrl` er feltet du brukar når ein coreAI-assistent skal vere tilgjengeleg berre for innlogga brukarar i ditt eige system. Når feltet er sett, kontaktar coreAI di eiga URL med tokenet til brukaren før chatwidgeten initialiserast, og berre brukarar som endepunktet ditt godkjenner med HTTP 200 får snakke med assistenten. Påloggingen, sesjonen og brukardatabasen vert hjå deg – coreAI eig ikkje logikken for kven som er kven.

## Når du bør bruke callbackUrl

Bruk `callbackUrl` når assistenten svarar på data som ikkje skal vere offentlege: kundeportalar, intranett, tilsettedokument eller fleirkundeløysingar der kvar brukar berre skal sjå sitt eige. Den typiske oppskrifta er at brukaren loggar inn hjå deg, du embeddar coreAI-widgeten på ei verna side, og widgeten sender med eit token (di eiga sesjons-ID, ein JWT, ein signert eingongskode – det du allereie brukar) som coreAI verifiserer mot endepunktet ditt før chatten startar.

Viss assistenten skal svare alle som besøkjer ei open side, treng du ikkje `callbackUrl`. Lat feltet stå tomt.

## To måtar å sende tokenet på

`callbackUrl` støttar to format, og coreAI vel metode ut frå korleis URL-en er skriven:

- **`{TOKEN}` i URL-en.** Skriv `https://mitt-system.no/validate?token={TOKEN}`, så byter coreAI plasshaldaren mot tokenet til brukaren og kallar URL-en med GET (fell tilbake til POST viss GET gjev 404). Plasshaldaren kan stå kvar som helst i URL-en, òg i stien: `https://mitt-system.no/validate/{TOKEN}` verkar òg.
- **Bearer-header.** Skriv ein fast URL utan `{TOKEN}`, til dømes `https://mitt-system.no/api/validate`. coreAI kallar då URL-en med POST og legg ved `Authorization: Bearer <token>` (fell tilbake til GET viss POST gjev 404).

Vel det som er enklast å byggje inn i di eksisterande auth-stack. Bearer-varianten passar best når du allereie har eit JSON-API som validerer tokens; URL-varianten er enklast når validatoren er eit standalone endpoint.

## Slik svarar endepunktet ditt

Endepunktet ditt må svare HTTP 200 med ein JSON-kropp for å sleppe brukaren gjennom. Alt anna – 401, 403, 500, nettverksfeil – vert tolka som avslag, og widgeten initialiserast ikkje. Viss svaret inneheld feltet `status`, må verdien vere `"success"`; alt anna vert avslått sjølv om statuskoden er 200.

JSON-svaret kan òg returnere éin eller fleire `external_id`-ar:

```json
{
  "status": "success",
  "external_id": ["customer-4711", "department-sales"]
}
```

Når feltet er til stades, låser coreAI samtalen til datakjeldene som matchar desse `external_id`-ane i kunnskapsbasen til assistenten. Det er denne mekanismen som gjer fleirkundeportalar praktiske: éin assistent, éin kunnskapsbase, men kvar brukar får berre sjå sine eigne ordrar, dokumenta til si eiga organisasjon, sitt eige innhald. Du avgjer scopinga i ditt eige endepunkt – coreAI les berre resultatet.

## Kva som vert skrudd av automatisk

Så snart ein assistent har ein `callbackUrl` sett, slår coreAI av tre overflater som elles ville omgått sjekken:

- **Offentleg søkjedemo** – søkje-endepunktet for upubliserte demo-treff svarar 403.
- **Direktelenkje til widgeten** – den delbare URL-en som opnar widgeten åleine i nettlesaren returnerer 403.
- **MCP-eksponering** – assistenten vert ikkje registrert som eit MCP-tool for AI-agentar.

Det er ingen veg utanom callbacken når han først er sett. Viss du vil eksponere noko offentleg igjen, må du fjerne `callbackUrl` eller opprette ein separat assistent for den opne overflata.

## Kvifor sjekken vert køyrd éin gong per widget-lasting

Tokenet vert validert nÃ¥r widgeten initialiserast – altsÃ¥ éin gong per sideinnlasting – og ikkje for kvart spørsmÃ¥l brukaren stiller eller kvar melding som vert strauma tilbake. Det er eit medvite val. Ã
 validere på nytt for kvart chat-kall ville lagt nettverkslatens frå endepunktet ditt mellom kvart spørsmål og kvart svar, men ikkje gjeve nokon reell tryggleiksvinst: tilgangen til assistenten vert allereie avgjord av at widgeten vart lasta i ein autentisert sesjon. Ein kompromittert sesjon hjå deg ville sloppe gjennom uansett kor ofte coreAI spurde.

I praksis tyder det at endepunktet ditt får éin HTTP-førespurnad per gong ein brukar opnar sida assistenten ligg på. Det er ei realistisk last å byggje for, òg for endepunkt som gjer tunge lookups mot databasen din.