> ## 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.

# Tillid og sikkerhed

> Forstå datahåndtering, levering af builds og ansvar for sikkerhed.

Ayakaleaf Pro kører i din infrastruktur. Du styrer dens data, adgang og netværksgrænser. Denne side forklarer standardsikkerhedsmodellen. Den beskriver også dit driftsmæssige ansvar.

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

Ayakaleaf Pro er en selvhostet forbedring af Overleaf Pro, og vores kildekode er tilgængelig på [ayaka-notes/ayakaleaf-pro](https://github.com/ayaka-notes/ayakaleaf-pro). Din installation bestemmer, hvor tjenesterne kører, og hvor dataene ligger.

Sikkerheden afhænger af din konfiguration og drift. Beskyt administratoradgangen, aktivér HTTPS, og vedligehold sikkerhedskopier.

Tak til OpenAI for deres venlige støtte. Vi bruger regelmæssigt [Codex Security](https://chatgpt.com/codex/cloud/security/findings) til at scanne vores repository for sikkerhedsproblemer og deler offentligt resultaterne af rettelser af sårbarheder.

### Hvor ender mine data?

Som standard forbliver applikationsdata i din installation:

* MongoDB gemmer bruger- og projektdata.
* Redis gemmer cache og data til samarbejde i realtid.
* Lokale volumes eller S3-kompatibel lagring indeholder projektfiler.

Kun webtjenesten er som standard eksponeret. Interne tjenester kommunikerer via Docker-netværket.

### Bliver mine data sendt til eller hentet fra tredjeparter?

Intet forlader din installation, medmindre du aktiverer en funktion, der kræver det. Ayakaleaf Pro sender *ingen telemetri, ingen brugsanalyser og ingen nedbrudsrapporter*. Fejlrapportering og analyser er deaktiveret i standardkonfigurationen.

Flere funktioner foretager slet ingen eksterne forespørgsler. Skabeloner gemmes og leveres fra din egen installation. Python-scriptkøreren udføres i brugerens browser via WebAssembly, og dens runtime leveres fra din egen webtjeneste i stedet for et offentligt CDN, så scriptkode og output aldrig når ud på netværket. Git Bridge kan kun nås på det interne Docker-netværk. Fuld projektsøgning, symbolpalet, sporede ændringer, projekthistorik og administrationspanelet er udelukkende lokale. Sandbox-kompileringscontainere oprettes med netværk deaktiveret.

De øvrige funktioners forespørgsler går til følgende destinationer. Hver forespørgsel stammer fra webtjenesten:

<Accordion title="AI-assistenter og søgning">
  AI-funktioner er deaktiveret som standard. Når de er aktiveret, sender chat og forslag til LaTeX-fejl prompts og relevant projektkontekst til det model-endpoint, der er konfigureret med `AI_BASE_URL`. Valgfri websøgning sender forespørgsler til den konfigurerede Tavily-kompatible tjeneste, og dokumentationssøgning sender forespørgsler til `DOCS_MCP_URL` (standard: `https://docs.overleaf.com/~gitbook/mcp`). Søgeresultater kan indgå i forespørgsler til modeludbyderen. Se [AI Integration](/da/on-premises/configuration/overleaf-toolkit/ai-integration "mention") for konfiguration og brugerindstillinger.
</Accordion>

<Accordion title="GitHub-integration">
  **GitHub-integration** kontakter `github.com` og `api.github.com`. Den aktiveres pr. bruger ved at tilknytte en GitHub-konto, og godkendelsen anmoder om scopes `read:org`, `repo` og `workflow`. Ved push uploades det fulde indhold af projektfilerne som Git-blobs, som derefter samles til trees og commits. Den udfører også branch-, reference-, compare- og merge-operationer og læser den tilknyttede kontos profil, organisationsmedlemskaber og liste over repositories. Projektindhold forlader din installation i begge retninger — betragt en tilknyttet GitHub-konto som en eksportvej for alle projekter, der er knyttet til den.
</Accordion>

<Accordion title="Zotero-integration">
  **Zotero-integration** kontakter `www.zotero.org` for godkendelse og `api.zotero.org` for biblioteksdata. Den aktiveres pr. bruger ved at tilknytte en Zotero-konto. OAuth-handshaket og brugerens API-nøgle sendes. Læsninger går kun én vej: referencebiblioteker hentes ind som BibTeX, og intet projektindhold uploades.
</Accordion>

<Accordion title="Mendeley-integration">
  **Mendeley-integration** kontakter `api.mendeley.com` for både godkendelse og biblioteksdata. Den aktiveres pr. bruger ved at tilknytte en Mendeley-konto. OAuth-handshaket anmoder om Mendeleys scope `all` — det eneste scope, deres API tilbyder — men Ayakaleaf udfører kun læsninger: referencebiblioteker og gruppebiblioteker hentes ind som BibTeX, og intet projektindhold uploades. Adgangstokens fornyes automatisk; når Mendeley tilbagekalder en tilladelse, kasseres de gemte legitimationsoplysninger, og brugeren bliver bedt om at tilknytte kontoen igen.
</Accordion>

<Accordion title="Dokumentationssider">
  **Dokumentationssider** hentes fra `https://learnwiki.overleaf.com`, hvilket kan konfigureres med `WIKI_URL`. Forespørgslerne foretages af webtjenesten, ikke af brugerens browser, så den eksterne wiki ser din server og aldrig dine brugeres adresser. Kun titlen på den ønskede side sendes, og svarene caches på disken. Peg `WIKI_URL` på dit eget mirror, eller bloker destinationen, hvis udgående dokumentationstrafik ikke er acceptabel.
</Accordion>

<Accordion title="E-maillevering">
  **E-maillevering** kontakter den SMTP-server eller mail-API, du konfigurerer; der er ingen standard. Modtageradresser og beskedindhold forlader din installation, herunder links til nulstilling af adgangskode og invitationer.
</Accordion>

<Accordion title="To valgfrie kontroller (PWD/reCAPTCHA)">
  <strong>To valgfrie kontroller er deaktiveret som standard.</strong> Kontrollen af kompromitterede adgangskoder er inaktiv, medmindre `HAVE_I_BEEN_PWNED_ENABLED` er sat; når den er aktiveret, sender den de første tegn af en SHA-1-hash af adgangskoden til `api.pwnedpasswords.com`, aldrig selve adgangskoden. CAPTCHA-verifikation er inaktiv, medmindre en reCAPTCHA-sitenøgle er konfigureret, og kontakter `www.google.com`, når den er aktiv.
</Accordion>

<Accordion title="Single sign-on (OAuth/LDAP/SAML)">
  **Single sign-on** når kun den identitetsudbyder, du angiver, og hvad der sendes dertil, afhænger af protokollen. Med LDAP forbinder webtjenesten direkte til dit katalog: den binder med den tjenestekonto, du konfigurerer, søger under den base, det filter og den attributliste, du definerer, og verificerer den adgangskode, der er indtastet i login-formularen, mod dit katalog, så brugernavnet og adgangskoden når katalogserveren. Hvis du aktiverer katalogbaserede kontakter, udføres en yderligere søgning for at udfylde kontaktlisten. Med OIDC udveksler webtjenesten autorisationskoden ved dit token-endpoint og kalder derefter dit user-info-endpoint, hvor den som standard anmoder om scopes `openid profile email`; dette kan konfigureres med `OVERLEAF_OIDC_SCOPE`. Med SAML går godkendelsesforespørgslen gennem brugerens browser til identitetsudbyderen i stedet for over en direkte serverforbindelse. I alle tre tilfælde kommer brugerens navn og e-mailadresse fra udbyderen i stedet for at blive sendt til den og gemmes derefter i den lokale brugerpost.
</Accordion>

<Accordion title="Tredjepartslegitimationsoplysninger">
  **Tredjepartslegitimationsoplysninger** — OAuth-tokens og API-nøgler — opbevares i MongoDB i brugerposten, krypteret med AES-256-CTR med et salt og en initialiseringsvektor pr. post. De gemmes aldrig i klartekst og skrives aldrig til logfiler. Krypteringsnøglen kommer fra `${PROVIDER}_CIPHER_PASSWORD`, hvis den er sat (som for Zotero og Mendeley); ellers genereres en ved første brug og gemmes i din data-volume med rettigheder, der kun giver ejeren adgang. Sikkerhedskopier den nøgle sammen med din data-volume: hvis den går tabt, kan gemte legitimationsoplysninger ikke dekrypteres, og alle brugere skal tilknytte deres konti igen.
</Accordion>

<Accordion title="Filer tilknyttet fra en URL">
  **Filer tilknyttet fra en URL** hentes af din installation på brugerens vegne, så destinationen er den adresse, brugeren angiver. Tilknyttede URL-filer er deaktiveret, medmindre du tilføjer `url` til `ENABLED_LINKED_FILE_TYPES`, og standardkonfigurationen indeholder den ikke. Eksterne ZIP- og TeX-importer via Open in Overleaf API bruger også den samme komponent `linked-url-proxy`. Direkte forespørgsler slår målets værtsnavn op og afviser begrænsede netværksområder, med forbehold for konfigurerede undtagelser for tilladte ressourcer. Når `OVERLEAF_LINKED_URL_OUTBOUND_PROXY` er konfigureret, er det den udgående proxy, der slår værtsnavne op, så den skal selv håndhæve begrænsninger for det interne netværk; applikationens netværkskontroller gælder kun for URL'er, der indeholder IP-adresser. Se [External URL — Outbound Proxy](/da/on-premises/configuration/overleaf-toolkit/external-url#outbound-proxy "mention") for detaljer. Disse forespørgsler henter den angivne URL i stedet for at uploade projektfiler.
</Accordion>

Hvis din politik kræver en tilladelsesliste for udgående trafik, skal du kun tillade de værter, hvis funktioner du har aktiveret — `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 dokumentation, `api.pwnedpasswords.com` for adgangskodekontrollen, `www.google.com` for CAPTCHA samt din egen mailserver og identitetsudbyder. Hvis AI-funktioner eller søgning er aktiveret, skal du også tillade de konfigurerede endpoints for model, websøgning og dokumentations-MCP. Afvis destinationer, der ikke kræves af dine aktiverede funktioner. Hvor udgående trafik skal inspiceres eller logges centralt, kan GitHub-, Zotero- og Mendeley-integrationerne hver især routes gennem en HTTP-proxy ved at sætte `GITHUB_SYNC_PROXY_URL`, `MENDELEY_PROXY_URL` og `ZOTERO_PROXY_URL`. Hentning af tilknyttede URL'er og fjernimporter kan bruge `OVERLEAF_LINKED_URL_OUTBOUND_PROXY`. Filer tilknyttet fra en URL kan ikke begrænses til en liste over værter, da destinationen vælges af brugeren på tidspunktet for forespørgslen; begræns den funktion via proxykomponentens egen indstilling for tilladte ressourcer, eller lad den være deaktiveret.

<Warning>
  Hvis du installerer Ayakaleaf Pro med [s3.md](/da/on-premises/configuration/overleaf-toolkit/s3 "mention")-lagring aktiveret, er de data, der gemmes i S3, så krypteret?

  *<strong>Nej.</strong>* Dataene er ikke krypteret. Alle historik-chunks, skabelonfiler, PDF'er og andre filer gemmes i klartekst. Hvis du bruger en ekstern S3-lagringsudbyder fra en tredjepart, skal du være meget opmærksom på datasikkerhed og privatliv.
</Warning>

### Er projektkompileringer isoleret?

Ayakaleaf Pro understøtter sandboxede kompileringer. Hver kompilering kører i en separat container. Sandbox-containere har som standard ingen netværksadgang. Det reducerer eksponeringen af interne netværksressourcer.

Sandboxede kompileringer kræver adgang til værtens Docker-socket. Begræns administration af værten til betroede operatører.

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

GitHub Actions bygger og udgiver Ayakaleaf Pros container-images. Images er tilgængelige fra det offentlige GitHub Container Registry.

Images understøtter `amd64` og `arm64`. Docker vælger den matchende arkitektur, når et image hentes.

Brug ikke tagget `latest` i produktion. Fastlås en eksplicit version, helst et image-digest.

Test hver opgradering i et ikke-produktionsmiljø. Verificer imaget, konfigurationen og integrationerne før udrulning.

### Er koden open source?

Ayakaleaf Pro og relaterede funktionsrepositories er offentligt tilgængelige. Det giver brugerne mulighed for at gennemgå ændringer og spore upstream-kilder.

Offentlig kildekode understøtter uafhængig gennemgang. Den garanterer dog ikke i sig selv reproducerbare release-builds.

Før du opgraderer, bør du gennemgå:

* Release-tagget eller committen.
* Imagets version eller digest.
* Tredjepartsafhængigheder og licenskrav.


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