Skip to main content
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. 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 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:
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 for konfiguration og brugerindstillinger.
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.
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.
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.
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.
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.
To valgfrie kontroller er deaktiveret som standard. 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.
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.
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.
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 for detaljer. Disse forespørgsler henter den angivne URL i stedet for at uploade projektfiler.
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.
Hvis du installerer Ayakaleaf Pro med s3.md-lagring aktiveret, er de data, der gemmes i S3, så krypteret?Nej. 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.

​
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.
Sidst ændret 5. oktober 2026