# Beskytt en assistent med din egen pålogging via callbackUrl `callbackUrl` er feltet du bruker når en coreAI-assistent skal være tilgjengelig bare for innloggede brukere i ditt eget system. Når feltet er satt, kontakter coreAI din egen URL med brukerens token før chatwidgeten initialiseres, og bare brukere som ditt endepunkt godkjenner med HTTP 200 får snakke med assistenten. Påloggingen, sesjonen og brukerdatabasen blir hos deg – coreAI eier ikke logikken for hvem som er hvem. ## Når du bør bruke callbackUrl Bruk `callbackUrl` når assistenten svarer på data som ikke skal være offentlig: kundeportaler, intranett, ansattdokumenter eller flerkundeløsninger der hver bruker bare skal se sitt eget. Den typiske oppskriften er at brukeren logger inn hos deg, du embedder coreAI-widgeten på en beskyttet side, og widgeten sender med et token (din egen sesjons-ID, en JWT, en signert engangskode – det du allerede bruker) som coreAI verifiserer mot ditt endepunkt før chatten starter. Hvis assistenten skal svare alle som besøker en åpen side, trenger du ikke `callbackUrl`. La feltet stå tomt. ## To måter å sende tokenet på `callbackUrl` støtter to formater, og coreAI velger metode ut fra hvordan URL-en er skrevet: - **`{TOKEN}` i URL-en.** Skriv `https://mitt-system.no/validate?token={TOKEN}`, så bytter coreAI plassholderen mot brukerens token og kaller URL-en med GET (faller tilbake til POST hvis GET gir 404). Plassholderen kan stå hvor som helst i URL-en, også i stien: `https://mitt-system.no/validate/{TOKEN}` virker også. - **Bearer-header.** Skriv en fast URL uten `{TOKEN}`, for eksempel `https://mitt-system.no/api/validate`. coreAI kaller da URL-en med POST og legger ved `Authorization: Bearer ` (faller tilbake til GET hvis POST gir 404). Velg det som er enklest å bygge inn i din eksisterende auth-stack. Bearer-varianten passer best når du allerede har et JSON-API som validerer tokens; URL-varianten er enklest når validatoren er en standalone endpoint. ## Slik svarer endepunktet ditt Endepunktet ditt må svare HTTP 200 med en JSON-kropp for å slippe brukeren gjennom. Alt annet – 401, 403, 500, nettverksfeil – tolkes som avslag, og widgeten initialiseres ikke. Hvis svaret inneholder feltet `status`, må verdien være `"success"`; alt annet avslår selv om statuskoden er 200. JSON-svaret kan også returnere én eller flere `external_id`-er: ```json { "status": "success", "external_id": ["customer-4711", "department-sales"] } ``` Når feltet er til stede, låser coreAI samtalen til datakildene som matcher disse `external_id`-ene i assistentens kunnskapsbase. Det er denne mekanismen som gjør flerkundeportaler praktiske: én assistent, én kunnskapsbase, men hver bruker får bare se sine egne ordrer, sin egen organisasjons dokumenter, sitt eget innhold. Du bestemmer scopingen i ditt eget endepunkt – coreAI leser bare resultatet. ## Hva som skrus av automatisk Så snart en assistent har en `callbackUrl` satt, slår coreAI av tre overflater som ellers ville omgått sjekken: - **Offentlig søkedemo** – søke-endepunktet for upubliserte demo-treff svarer 403. - **Direktelenke til widgeten** – den delbare URL-en som åpner widgeten alene i nettleseren returnerer 403. - **MCP-eksponering** – assistenten registreres ikke som en MCP-tool for AI-agenter. Det er ingen vei utenom callbacken når den først er satt. Hvis du vil eksponere noe offentlig igjen, må du fjerne `callbackUrl` eller opprette en separat assistent for den åpne overflaten. ## Hvorfor sjekken kjøres én gang per widget-lasting Tokenet valideres når widgeten initialiseres – altså én gang per sideinnlasting – og ikke for hvert spørsmål brukeren stiller eller hver melding som strømmes tilbake. Det er et bevisst valg. à validere på nytt for hvert chat-kall ville lagt nettverkslatens fra ditt endepunkt mellom hvert spørsmål og hvert svar, men ikke gitt noen reell sikkerhetsgevinst: tilgangen til assistenten avgjøres allerede av at widgeten ble lastet i en autentisert sesjon. En kompromittert sesjon hos deg ville sluppet gjennom uansett hvor ofte coreAI spurte. I praksis betyr det at endepunktet ditt får én HTTP-forespørsel per gang en bruker åpner siden assistenten ligger på. Det er en realistisk last å bygge for, også for endepunkter som gjør tunge lookups mot databasen din.