> ## Documentation Index
> Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Tillit og sikkerhet

> Forstå datahåndtering, levering av bygg og ansvar for sikkerhet.

Ayakaleaf Pro kjører i din infrastruktur. Du kontrollerer dataene, tilgangen og nettverksgrensene. Denne siden forklarer standard sikkerhetsmodell. Den angir også hvilket driftsansvar du har.

### Er Ayakaleaf Pro pålitelig og sikker?

Ayakaleaf Pro er en selvdriftet videreutvikling av Overleaf Pro, og kildekoden vår er tilgjengelig på [ayaka-notes/ayakaleaf-pro](https://github.com/ayaka-notes/ayakaleaf-pro). Installasjonen din bestemmer hvor tjenestene kjører og hvor dataene ligger.

Sikkerheten avhenger av konfigurasjonen og driften din. Beskytt administratortilgang, aktiver HTTPS og ta vare på sikkerhetskopier.

Takk til OpenAI for velvillig støtte. Vi bruker jevnlig [Codex Security](https://chatgpt.com/codex/cloud/security/findings) til å skanne repositoriet vårt for sikkerhetsproblemer og deler resultatene av sårbarhetsrettinger offentlig.

### Hvor havner dataene mine?

Som standard forblir applikasjonsdata i installasjonen din:

* MongoDB lagrer bruker- og prosjektdata.
* Redis lagrer buffer og data for sanntidssamarbeid.
* Lokale volumer eller S3-kompatibel lagring inneholder prosjektfiler.

Bare webtjenesten er eksponert som standard. Interne tjenester kommuniserer via Docker-nettverket.

### Vil dataene mine bli sendt til eller hentet fra tredjeparter?

Ingenting forlater installasjonen din med mindre du aktiverer en funksjon som krever det. Ayakaleaf Pro sender *ingen telemetri, ingen bruksanalyse og ingen krasjrapporter*. Feilrapportering og analyse er deaktivert i standardkonfigurasjonen.

Flere funksjoner gjør aldri eksterne forespørsler i det hele tatt. Maler lagres og leveres fra din egen installasjon. Python-skriptkjøreren kjører i brukerens nettleser via WebAssembly, og kjøretidsmiljøet leveres fra din egen webtjeneste i stedet for et offentlig CDN, så skriptkode og utdata når aldri nettverket. Git Bridge er bare tilgjengelig på det interne Docker-nettverket. Fullstendig prosjektsøk, symbolpaletten, sporede endringer, prosjekthistorikk og administrasjonspanelet er helt lokale. Containere for sandkassekompilering opprettes med nettverk deaktivert.

De øvrige funksjonene sender forespørsler til følgende mål. Hver forespørsel stammer fra webtjenesten:

<Accordion title="AI-assistenter og søk">
  AI-funksjoner er deaktivert som standard. Når de er aktivert, sender chat og forslag til LaTeX-feil ledetekster og relevant prosjektkontekst til modellendepunktet som er konfigurert med `AI_BASE_URL`. Valgfritt nettsøk sender spørringer til den konfigurerte Tavily-kompatible tjenesten, og dokumentasjonssøk sender spørringer til `DOCS_MCP_URL` (standard: `https://docs.overleaf.com/~gitbook/mcp`). Søkeresultater kan inkluderes i forespørsler til modelleverandøren. Se [AI Integration](/no/on-premises/configuration/overleaf-toolkit/ai-integration "mention") for konfigurasjon og brukerkontroller.
</Accordion>

<Accordion title="GitHub-integrasjon">
  **GitHub-integrasjonen** kontakter `github.com` og `api.github.com`. Den aktiveres per bruker ved å koble til en GitHub-konto, og autorisasjonen ber om omfangene `read:org`, `repo` og `workflow`. Ved push lastes hele innholdet i prosjektfilene opp som Git-blober, som deretter settes sammen til trær og commits. Den utfører også operasjoner på grener, referanser, sammenligninger og sammenslåinger, og leser den tilkoblede kontoens profil, organisasjonsmedlemskap og repositorieliste. Prosjektinnhold forlater installasjonen i begge retninger — betrakt en tilkoblet GitHub-konto som en eksportvei for alle prosjekter som er knyttet til den.
</Accordion>

<Accordion title="Zotero-integrasjon">
  **Zotero-integrasjonen** kontakter `www.zotero.org` for autorisasjon og `api.zotero.org` for biblioteksdata. Den aktiveres per bruker ved å koble til en Zotero-konto. OAuth-håndtrykket og brukerens API-nøkkel sendes. Lesing skjer bare i én retning: referansebiblioteker hentes inn som BibTeX, og ikke noe prosjektinnhold lastes opp.
</Accordion>

<Accordion title="Mendeley-integrasjon">
  **Mendeley-integrasjonen** kontakter `api.mendeley.com` både for autorisasjon og biblioteksdata. Den aktiveres per bruker ved å koble til en Mendeley-konto. OAuth-håndtrykket ber om Mendeleys omfang `all` — det eneste omfanget API-et tilbyr — men Ayakaleaf utfører bare lesing: referansebiblioteker og gruppebiblioteker hentes inn som BibTeX, og ikke noe prosjektinnhold lastes opp. Tilgangstokener fornyes automatisk; når Mendeley tilbakekaller en tillatelse, forkastes den lagrede legitimasjonen, og brukeren blir bedt om å koble til kontoen på nytt.
</Accordion>

<Accordion title="Dokumentasjonssider">
  **Dokumentasjonssider** hentes fra `https://learnwiki.overleaf.com`, noe som kan konfigureres med `WIKI_URL`. Forespørslene gjøres av webtjenesten, ikke av brukerens nettleser, så wikien oppstrøms ser serveren din og aldri brukernes adresser. Bare tittelen på den forespurte siden sendes, og svarene bufres på disk. Pek `WIKI_URL` mot ditt eget speil, eller blokker målet, hvis utgående dokumentasjonstrafikk ikke er akseptabelt.
</Accordion>

<Accordion title="E-postlevering">
  **E-postlevering** kontakter den SMTP-serveren eller det e-post-API-et du konfigurerer; det finnes ingen standard. Mottakeradresser og meldingsinnhold forlater installasjonen, inkludert lenker for tilbakestilling av passord og invitasjoner.
</Accordion>

<Accordion title="To valgfrie kontroller (PWD/reCAPTCHA)">
  <strong>To valgfrie kontroller er deaktivert som standard.</strong> Kontrollen av kompromitterte passord er inaktiv med mindre `HAVE_I_BEEN_PWNED_ENABLED` er satt; når den er aktivert, sender den de første tegnene i en SHA-1-hash av passordet til `api.pwnedpasswords.com`, aldri selve passordet. CAPTCHA-verifisering er inaktiv med mindre en reCAPTCHA-nettstedsnøkkel er konfigurert, og kontakter `www.google.com` når den er aktiv.
</Accordion>

<Accordion title="Enkel pålogging (OAuth/LDAP/SAML)">
  **Enkel pålogging** når bare identitetsleverandøren du oppgir, og hva som sendes dit, avhenger av protokollen. Med LDAP kobler webtjenesten seg direkte til katalogen din: den binder seg med tjenestekontoen du konfigurerer, søker under basen, filteret og attributtlisten du definerer, og verifiserer passordet som er skrevet inn i innloggingsskjemaet mot katalogen, slik at brukernavnet og passordet når katalogserveren. Aktivering av katalogbaserte kontakter fører til et ekstra søk for å fylle kontaktlisten. Med OIDC utveksler webtjenesten autorisasjonskoden ved token-endepunktet ditt og kaller deretter brukerinfo-endepunktet, og ber som standard om omfangene `openid profile email`; dette kan konfigureres med `OVERLEAF_OIDC_SCOPE`. Med SAML går autentiseringsforespørselen via brukerens nettleser til identitetsleverandøren i stedet for over en direkte servertilkobling. I alle tre tilfeller kommer brukerens navn og e-postadresse fra leverandøren i stedet for å bli sendt til den, og lagres deretter i den lokale brukeroppføringen.
</Accordion>

<Accordion title="Tredjepartslegitimasjon">
  **Tredjepartslegitimasjon** — OAuth-tokener og API-nøkler — lagres i MongoDB i brukeroppføringen, kryptert med AES-256-CTR med salt og initialiseringsvektor per oppføring. De lagres aldri i klartekst og skrives aldri til logger. Krypteringsnøkkelen hentes fra `${PROVIDER}_CIPHER_PASSWORD` hvis den er satt (som for Zotero og Mendeley); ellers genereres en ved første bruk og lagres i datavolumet ditt med tillatelser bare for eieren. Ta sikkerhetskopi av den nøkkelen sammen med datavolumet: hvis den går tapt, kan ikke lagret legitimasjon dekrypteres, og alle brukere må koble til kontoene sine på nytt.
</Accordion>

<Accordion title="Filer lenket fra en URL">
  **Filer lenket fra en URL** hentes av installasjonen din på vegne av brukeren, så målet er den adressen brukeren oppgir. Lenkede URL-filer er deaktivert med mindre du legger til `url` i `ENABLED_LINKED_FILE_TYPES`, og standardkonfigurasjonen inkluderer det ikke. Eksterne ZIP- og TeX-importer via Open in Overleaf-API-et bruker også den samme `linked-url-proxy`-komponenten. Direkte forespørsler slår opp vertsnavnet til målet og avviser begrensede nettverksområder, med forbehold om konfigurerte unntak for tillatte ressurser. Når `OVERLEAF_LINKED_URL_OUTBOUND_PROXY` er konfigurert, er det den utgående proxyen som slår opp vertsnavn, så den må selv håndheve begrensninger for internt nettverk; applikasjonens nettverkskontroller gjelder bare URL-er som inneholder IP-adresser. Se [External URL — Outbound Proxy](/no/on-premises/configuration/overleaf-toolkit/external-url#outbound-proxy "mention") for detaljer. Disse forespørslene henter den oppgitte URL-en i stedet for å laste opp prosjektfiler.
</Accordion>

Hvis retningslinjene dine krever en tillatelsesliste for utgående trafikk, tillater du bare vertene for funksjonene du har aktivert — `github.com` og `api.github.com` for GitHub, `www.zotero.org` og `api.zotero.org` for Zotero, `api.mendeley.com` for Mendeley, `learnwiki.overleaf.com` eller din egen `WIKI_URL` for dokumentasjon, `api.pwnedpasswords.com` for passordkontrollen, `www.google.com` for CAPTCHA, i tillegg til din egen e-postserver og identitetsleverandør. Hvis AI-funksjoner eller søk er aktivert, må du også tillate de konfigurerte endepunktene for modell, nettsøk og dokumentasjons-MCP. Avvis mål som ikke kreves av funksjonene du har aktivert. Der utgående trafikk må inspiseres eller logges sentralt, kan GitHub-, Zotero- og Mendeley-integrasjonene hver for seg rutes gjennom en HTTP-proxy ved å sette `GITHUB_SYNC_PROXY_URL`, `MENDELEY_PROXY_URL` og `ZOTERO_PROXY_URL`. Henting av lenkede URL-er og eksterne importer kan bruke `OVERLEAF_LINKED_URL_OUTBOUND_PROXY`. Filer lenket fra en URL kan ikke begrenses til en liste over verter, siden målet velges av brukeren på forespørselstidspunktet; begrens den funksjonen via proxykomponentens egen innstilling for tillatte ressurser, eller la den være deaktivert.

<Warning>
  Hvis du installerer Ayakaleaf Pro med [s3.md](/no/on-premises/configuration/overleaf-toolkit/s3 "mention")-lagring aktivert, er dataene som lagres i S3 kryptert?

  *<strong>Nei.</strong>* Dataene er ikke kryptert. Alle historikkbiter, malfiler, PDF-er og andre filer lagres i klartekst. Hvis du bruker en ekstern S3-lagringsleverandør fra en tredjepart, må du være spesielt oppmerksom på datasikkerhet og personvern.
</Warning>

### Er prosjektkompileringer isolert?

Ayakaleaf Pro støtter sandkassekompilering. Hver kompilering kjører i en egen container. Sandkassecontainere har ingen nettverkstilgang som standard. Dette reduserer eksponeringen mot interne nettverksressurser.

Sandkassekompilering krever tilgang til Docker-socketen på verten. Begrens administrasjon av verten til betrodde operatører.

### Kan jeg stole på CI-bygg og container-images?

GitHub Actions bygger og publiserer container-imagene for Ayakaleaf Pro. Imagene er tilgjengelige fra det offentlige GitHub Container Registry.

Imagene støtter `amd64` og `arm64`. Docker velger arkitekturen som passer, når et image hentes.

Ikke bruk taggen `latest` i produksjon. Lås til en eksplisitt versjon, helst en image-digest.

Test hver oppgradering i et miljø som ikke er produksjon. Verifiser imaget, konfigurasjonen og integrasjonene før utrulling.

### Er koden åpen kildekode?

Ayakaleaf Pro og tilhørende funksjonsrepositorier er offentlig tilgjengelige. Dette lar brukerne gå gjennom endringer og spore kilder oppstrøms.

Offentlig kildekode muliggjør uavhengig gjennomgang. Den garanterer imidlertid ikke i seg selv reproduserbare utgivelsesbygg.

Før du oppgraderer, bør du gå gjennom:

* Utgivelsestaggen eller commiten.
* Imageversjonen eller digesten.
* Tredjepartsavhengigheter og lisenskrav.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.