Skip to main content
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. 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 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:
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 for konfigurasjon og brukerkontroller.
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.
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.
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.
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.
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.
To valgfrie kontroller er deaktivert som standard. 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.
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.
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.
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 for detaljer. Disse forespørslene henter den oppgitte URL-en i stedet for å laste opp prosjektfiler.
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.
Hvis du installerer Ayakaleaf Pro med s3.md-lagring aktivert, er dataene som lagres i S3 kryptert?Nei. 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.

​
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.
Sist endret 5. oktober 2026