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

# Förtroende och säkerhet

> Förstå datahantering, leverans av byggen och ansvar för säkerheten.

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](https://github.com/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](https://chatgpt.com/codex/cloud/security/findings) 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:

<Accordion title="AI-assistenter och sökning">
  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](/sv/on-premises/configuration/overleaf-toolkit/ai-integration "mention") för konfiguration och användarinställningar.
</Accordion>

<Accordion title="GitHub-integration">
  **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.
</Accordion>

<Accordion title="Zotero-integration">
  **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.
</Accordion>

<Accordion title="Mendeley-integration">
  **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.
</Accordion>

<Accordion title="Dokumentationssidor">
  **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.
</Accordion>

<Accordion title="E-postleverans">
  **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.
</Accordion>

<Accordion title="Två valfria kontroller (PWD/reCAPTCHA)">
  <strong>Två valfria kontroller är inaktiverade som standard.</strong> 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.
</Accordion>

<Accordion title="Enkel inloggning (OAuth/LDAP/SAML)">
  **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.
</Accordion>

<Accordion title="Autentiseringsuppgifter för tredje part">
  **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.
</Accordion>

<Accordion title="Filer länkade från en URL">
  **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](/sv/on-premises/configuration/overleaf-toolkit/external-url#outbound-proxy "mention") för mer information. Dessa anrop hämtar den angivna URL:en i stället för att ladda upp projektfiler.
</Accordion>

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.

<Warning>
  Om du driftsätter Ayakaleaf Pro med [s3.md](/sv/on-premises/configuration/overleaf-toolkit/s3 "mention")-lagring aktiverad, är data som lagras i S3 krypterade?

  *<strong>Nej.</strong>* 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.
</Warning>

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


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