Skip to main content
Ayakaleaf Pro körs i din infrastruktur. Du kontrollerar dess data, åtkomst och nätverksgränser. Den här sidan förklarar standardmodellen för säkerhet. Den beskriver också ditt operativa ansvar.

​
Är Ayakaleaf Pro tillförlitligt och säkert?

Ayakaleaf Pro är en självhostad förbättring av Overleaf Pro, och vår källkod finns på ayaka-notes/ayakaleaf-pro. Din driftsättning styr var tjänsterna körs och var data finns. Säkerheten beror på din konfiguration och drift. Skydda administratörsåtkomsten, aktivera HTTPS och underhåll säkerhetskopior. Tack till OpenAI för deras vänliga stöd. Vi kommer regelbundet att använda Codex Security för att söka igenom vårt repository efter säkerhetsproblem och offentligt dela resultaten av åtgärdade sårbarheter.

​
Vart tar mina data vägen?

Som standard stannar applikationsdata inom din driftsättning:
  • MongoDB lagrar användar- och projektdata.
  • Redis lagrar cache och data för samarbete i realtid.
  • Lokala volymer eller S3-kompatibel lagring innehåller projektfiler.
Endast webbtjänsten exponeras som standard. Interna tjänster kommunicerar via Docker-nätverket.

​
Skickas mina data till eller hämtas de från några tredje parter?

Ingenting lämnar din driftsättning om du inte aktiverar en funktion som kräver det. Ayakaleaf Pro skickar ingen telemetri, ingen användningsanalys och inga kraschrapporter. Felrapportering och analys är inaktiverade i standardkonfigurationen. Flera funktioner gör aldrig några externa anrop alls. Mallar lagras och levereras från din egen driftsättning. Python Script Runner körs i användarens webbläsare via WebAssembly, och dess runtime levereras från din egen webbtjänst i stället för ett offentligt CDN, så skriptkod och utdata når aldrig nätverket. Git Bridge kan bara nås på det interna Docker-nätverket. Fullständig projektsökning, symbolpaletten, spårning av ändringar, projekthistorik och adminpanelen är helt lokala. Containrar för kompilering i sandlåda skapas med nätverk inaktiverat. Övriga funktioners anrop når följande destinationer. Varje anrop utgår från webbtjänsten:
AI-funktioner är inaktiverade som standard. När de är aktiverade skickar chatten och förslagen för LaTeX-fel prompter och relevant projektkontext till den modellendpoint som konfigurerats med AI_BASE_URL. Valfri webbsökning skickar sökfrågor till den konfigurerade Tavily-kompatibla tjänsten, och dokumentationssökning skickar sökfrågor till DOCS_MCP_URL (standard: https://docs.overleaf.com/~gitbook/mcp). Sökresultat kan inkluderas i anrop till modellleverantören. Se AI Integration för konfiguration och användarinställningar.
GitHub-integrationen kontaktar github.com och api.github.com. Den aktiveras per användare genom att ett GitHub-konto länkas, och auktoriseringen begär behörighetsomfången read:org, repo och workflow. Vid push laddas hela projektfilernas innehåll upp som Git-blobbar, som sedan sätts samman till träd och commits. Den utför även gren-, referens-, jämförelse- och sammanslagningsåtgärder och läser det länkade kontots profil, organisationsmedlemskap och lista över repositories. Projektinnehåll lämnar din driftsättning i båda riktningarna — betrakta ett länkat GitHub-konto som en exportväg för alla projekt som är kopplade till det.
Zotero-integrationen kontaktar www.zotero.org för auktorisering och api.zotero.org för biblioteksdata. Den aktiveras per användare genom att ett Zotero-konto länkas. OAuth-handskakningen och användarens API-nyckel skickas. Läsningar sker i en riktning: referensbibliotek hämtas in som BibTeX och inget projektinnehåll laddas upp.
Mendeley-integrationen kontaktar api.mendeley.com för både auktorisering och biblioteksdata. Den aktiveras per användare genom att ett Mendeley-konto länkas. OAuth-handskakningen begär Mendeleys omfång all — det enda omfång som deras API erbjuder — men Ayakaleaf utför bara läsningar: referensbibliotek och gruppbibliotek hämtas in som BibTeX och inget projektinnehåll laddas upp. Åtkomsttoken förnyas automatiskt; när Mendeley återkallar ett medgivande kasseras de lagrade autentiseringsuppgifterna och användaren ombeds länka kontot igen.
Dokumentationssidor hämtas från https://learnwiki.overleaf.com, vilket kan konfigureras med WIKI_URL. Anropen görs av webbtjänsten, inte av användarens webbläsare, så uppströmswikin ser din server och aldrig dina användares adresser. Endast den begärda sidans titel skickas, och svaren cachas på disk. Peka WIKI_URL mot din egen spegel, eller blockera destinationen, om utgående dokumentationstrafik inte är acceptabel.
E-postleverans kontaktar den SMTP-server eller det e-post-API du konfigurerar; det finns ingen standard. Mottagaradresser och meddelandeinnehåll lämnar din driftsättning, inklusive länkar för lösenordsåterställning och inbjudningar.
Två valfria kontroller är inaktiverade som standard. Kontrollen av komprometterade lösenord är inaktiv om inte HAVE_I_BEEN_PWNED_ENABLED är satt; när den är aktiverad skickas de första tecknen i en SHA-1-hash av lösenordet till api.pwnedpasswords.com, aldrig själva lösenordet. CAPTCHA-verifiering är inaktiv om ingen reCAPTCHA-webbplatsnyckel är konfigurerad, och kontaktar www.google.com när den är aktiv.
Enkel inloggning når bara den identitetsleverantör du anger, och vad som skickas dit beror på protokollet. Med LDAP ansluter webbtjänsten direkt till din katalog: den binder med det tjänstekonto du konfigurerar, söker under den bas, det filter och den attributlista du definierar och verifierar lösenordet som angetts i inloggningsformuläret mot din katalog, så att användarnamn och lösenord når katalogservern. Om du aktiverar katalogbaserade kontakter görs ytterligare en sökning för att fylla i kontaktlistan. Med OIDC byter webbtjänsten in auktoriseringskoden hos din token-endpoint och anropar sedan din user-info-endpoint, och begär som standard omfången openid profile email; detta kan konfigureras med OVERLEAF_OIDC_SCOPE. Med SAML går autentiseringsbegäran via användarens webbläsare till identitetsleverantören i stället för via en direkt serveranslutning. I alla tre fallen kommer användarens namn och e-postadress från leverantören i stället för att skickas till den, och lagras sedan i den lokala användarposten.
Autentiseringsuppgifter för tredje part — OAuth-token och API-nycklar — lagras i MongoDB i användarposten, krypterade med AES-256-CTR med ett salt och en initieringsvektor per post. De lagras aldrig i klartext och skrivs aldrig till loggar. Krypteringsnyckeln hämtas från ${PROVIDER}_CIPHER_PASSWORD om den är satt (som för Zotero och Mendeley); annars genereras en vid första användningen och sparas i din datavolym med behörigheter endast för ägaren. Säkerhetskopiera nyckeln tillsammans med din datavolym: om den går förlorad kan lagrade autentiseringsuppgifter inte dekrypteras och alla användare måste länka sina konton igen.
Filer länkade från en URL hämtas av din driftsättning för användarens räkning, så destinationen är den adress som användaren anger. Länkade URL-filer är inaktiverade om du inte lägger till url i ENABLED_LINKED_FILE_TYPES, och standardkonfigurationen innehåller inte det värdet. Externa ZIP- och TeX-importer via Open in Overleaf API använder också samma komponent, linked-url-proxy. Direkta anrop slår upp målets värdnamn och avvisar begränsade nätverksintervall, med förbehåll för konfigurerade undantag för tillåtna resurser. När OVERLEAF_LINKED_URL_OUTBOUND_PROXY är konfigurerad slår den utgående proxyn upp värdnamnen, så den måste själv upprätthålla begränsningarna för interna nätverk; applikationens nätverkskontroller gäller bara URL:er som innehåller IP-adresser. Se External URL — Outbound Proxy för mer information. Dessa anrop hämtar den angivna URL:en i stället för att ladda upp projektfiler.
Om din policy kräver en lista över tillåtna utgående destinationer tillåter du bara värdarna för de funktioner du har aktiverat — github.com och api.github.com för GitHub, www.zotero.org och api.zotero.org för Zotero, api.mendeley.com för Mendeley, learnwiki.overleaf.com eller din egen WIKI_URL för dokumentation, api.pwnedpasswords.com för lösenordskontrollen, www.google.com för CAPTCHA, samt din egen e-postserver och identitetsleverantör. Om AI-funktioner eller sökning är aktiverade tillåter du även de konfigurerade endpoints för modell, webbsökning och dokumentations-MCP. Neka destinationer som inte krävs av dina aktiverade funktioner. Där utgående trafik måste inspekteras eller loggas centralt kan integrationerna för GitHub, Zotero och Mendeley var och en dirigeras via en HTTP-proxy genom att sätta GITHUB_SYNC_PROXY_URL, MENDELEY_PROXY_URL och ZOTERO_PROXY_URL. Hämtning av länkade URL:er och fjärrimporter kan använda OVERLEAF_LINKED_URL_OUTBOUND_PROXY. Filer länkade från en URL kan inte begränsas till en lista över värdar, eftersom destinationen väljs av användaren när anropet görs; begränsa den funktionen via proxykomponentens egen inställning för tillåtna resurser, eller låt den vara inaktiverad.
Om du driftsätter Ayakaleaf Pro med s3.md-lagring aktiverad, är data som lagras i S3 krypterade?Nej. Data är inte krypterade. Alla historikdelar, mallfiler, PDF-filer och andra filer lagras i klartext. Om du använder en extern S3-lagringsleverantör från tredje part bör du vara mycket uppmärksam på datasäkerhet och integritet.

​
Är projektkompileringar isolerade?

Ayakaleaf Pro stöder kompilering i sandlåda. Varje kompilering körs i en separat container. Sandlådecontainrar har ingen nätverksåtkomst som standard. Det minskar exponeringen mot interna nätverksresurser. Kompilering i sandlåda kräver åtkomst till värdens Docker-socket. Begränsa administrationen av värden till betrodda operatörer.

​
Kan jag lita på CI-byggen och container-images?

GitHub Actions bygger och publicerar Ayakaleaf Pros container-images. Imagesen finns tillgängliga i det offentliga GitHub Container Registry. Imagesen stöder amd64 och arm64. Docker väljer den matchande arkitekturen när en image hämtas. Använd inte taggen latest i produktion. Lås en explicit version, helst en image-digest. Testa varje uppgradering i en miljö som inte är produktion. Verifiera imagen, konfigurationen och integrationerna före utrullning.

​
Är koden öppen källkod?

Ayakaleaf Pro och tillhörande funktionsrepositories är offentligt tillgängliga. Det gör att användare kan granska ändringar och spåra uppströmskällor. Offentlig källkod möjliggör oberoende granskning. Den garanterar dock inte i sig reproducerbara versionsbyggen. Innan du uppgraderar bör du granska:
  • Versionstaggen eller commiten.
  • Imagens version eller digest.
  • Beroenden från tredje part och licenskrav.
Senast ändrad 5 oktober 2026