> For the complete documentation index, see [llms.txt](https://ayakaleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ayakaleaf-pro.ayaka.space/on-premises/no/readme/tillit-og-sikkerhet.md). # Tillit og sikkerhet Ayakaleaf Pro kjører i infrastrukturen din. Du kontrollerer dataene, tilgangen og nettverksgrensene. Denne siden forklarer standard sikkerhetsmodell. Den identifiserer også dine driftsansvar. ### Er Ayakaleaf Pro pålitelig og sikker? Ayakaleaf Pro er et selvhostet tillegg til Overleaf Pro, og kildekoden vår er tilgjengelig på [ayaka-notes/ayakaleaf](https://github.com/ayaka-notes/ayakaleaf-pro). Distribusjonen din kontrollerer hvor tjenestene kjører og hvor dataene befinner seg. Sikkerhet avhenger av konfigurasjonen og driften din. Beskytt administratortilgang, aktiver HTTPS og vedlikehold sikkerhetskopier. Takket være OpenAI for den vennlige støtten deres. Vi vil jevnlig bruke [Codex Security](https://chatgpt.com/codex/cloud/security/findings) til å skanne repositoriet vårt for sikkerhetsproblemer og offentlig dele resultatene av sårbarhetsfiksene. ### Hvor blir dataene mine sendt? Som standard blir applikasjonsdata værende i distribusjonen din: * MongoDB lagrer bruker- og prosjektdata. * Redis lagrer hurtigbuffer- og sanntidssamarbeidsdata. * 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 tredjepart? Ingenting forlater distribusjonen 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 serveres fra din egen distribusjon. Python-skriptkjøreren kjøres i brukerens nettleser via WebAssembly, og kjøretiden serveres 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. Full prosjektsøk, symbolpalett, spor endringer, prosjekthistorikk og administrasjonspanelet er helt lokale. Sandkassecontainere for kompilering opprettes med nettverk deaktivert. De resterende funksjonsforespørslene når følgende destinasjoner. Hver forespørsel kommer fra webtjenesten:
GitHub-integrasjon **GitHub-integrasjon** kontakter `github.com` og `api.github.com`. Den aktiveres per bruker ved å koble til en GitHub-konto, og autorisasjonen ber om `read:org`, `repo`, og `workflow` tilganger. Ved push lastes fullt prosjektfilinnhold opp som Git-blobs, som deretter settes sammen til trær og commits. Den utfører også gren-, referanse-, sammenlignings- og sammenslåingsoperasjoner, og leser den tilkoblede kontoens profil, organisasjonstilknytninger og repository-liste. Prosjektinnhold forlater distribusjonen din i begge retninger — se på en tilkoblet GitHub-konto som en eksportvei for hvert prosjekt som er knyttet til den.
Zotero-integrasjon **Zotero-integrasjon** kontakter `www.zotero.org` for autorisasjon og `api.zotero.org` for bibliotekdata. Den aktiveres per bruker ved å koble til en Zotero-konto. OAuth-håndtrykket og brukerens API-nøkkel sendes. Lesinger er ensrettede: referansebiblioteker hentes inn som BibTeX, og noe prosjektinnhold lastes ikke opp.
Mendeley-integrasjon **Mendeley-integrasjon** kontakter `api.mendeley.com` for både autorisasjon og bibliotekdata. Den aktiveres per bruker ved å koble til en Mendeley-konto. OAuth-håndtrykket ber om Mendeleys `all` scope — det eneste scopet API-et deres tilbyr — men Ayakaleaf utfører bare lesinger: referansebiblioteker og gruppekbiblioteker hentes inn som BibTeX, og noe prosjektinnhold lastes ikke opp. Tilgangstokener fornyes automatisk; når Mendeley tilbakekaller en tillatelse, forkastes den lagrede legitimasjonen og brukeren blir bedt om å koble til kontoen igjen.
Dokumentsider **Dokumentsider** hentes fra `https://learnwiki.overleaf.com`, kan konfigureres med `WIKI_URL`. Forespørsler gjøres av webtjenesten, ikke av brukerens nettleser, så den overordnede wikien ser serveren din og aldri brukernes adresser. Bare den forespurte sidetittelen sendes, og svar bufres på disk. Pek `WIKI_URL` til din egen speiling, eller blokker destinasjonen, hvis utgående dokumentasjonstrafikk ikke er akseptabel.
E-postlevering **E-postlevering** kontakter hvilken som helst SMTP-server eller e-post-API du konfigurerer; det finnes ingen standard. Mottakeradresser og meldingsinnhold forlater distribusjonen din, inkludert lenker for tilbakestilling av passord og invitasjon.
To valgfrie kontroller (PWD/reCAPTCHA) **To valgfrie kontroller er deaktivert som standard.** Kontrollen for kompromitterte passord er inaktiv med mindre `HAVE_I_BEEN_PWNED_ENABLED` er satt; når den er aktiv, 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-nettstednøkkel er konfigurert, og kontakter `www.google.com` når den er aktiv.
Enkel pålogging (OAuth/LDAP/SAML) **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 base, filter og attributtliste du definerer, og verifiserer passordet som er skrevet inn i innloggingsskjemaet mot katalogen din, slik at brukernavnet og passordet når katalogserveren. Når kontakter med katalogstøtte aktiveres, utføres et ekstra søk for å fylle ut kontaktlisten. Med OIDC utveksler webtjenesten autorisasjonskoden ved token-endepunktet ditt og kaller deretter user-info-endepunktet ditt, og ber om `openid profile email` scopene som standard; dette kan konfigureres med `OVERLEAF_OIDC_SCOPE`. Med SAML går autentiseringsforespørselen gjennom brukerens nettleser til identitetsleverandøren i stedet for over en direkte serverforbindelse. 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 brukerposten.
Tredjepartslegitimasjon **Tredjepartslegitimasjon** — OAuth-tokener og API-nøkler — lagres i MongoDB på brukerposten, kryptert med AES-256-CTR under en salt og initialiseringsvektor per post. De lagres aldri i klartekst og skrives aldri til logger. Krypteringsnøkkelen kommer fra `${PROVIDER}_CIPHER_PASSWORD` hvis satt (som Zotero og Mendey); ellers genereres en ved første bruk og lagres i datavolumet ditt med rettigheter kun for eier. Ta sikkerhetskopi av den nøkkelen sammen med datavolumet ditt: hvis den går tapt, kan lagret legitimasjon ikke dekrypteres, og hver bruker må koble til kontoene sine på nytt.
Filer som er lenket fra en URL **Filer som er lenket fra en URL** hentes av distribusjonen din på brukerens vegne, så destinasjonen er hvilken som helst adresse brukeren oppgir. Dette er den eneste funksjonen hvis utgående mål ikke er en fast liste. Den er deaktivert med mindre du `url` til `ENABLED_LINKED_FILE_TYPES`, og standardkonfigurasjonen inkluderer den ikke. Når den er aktivert, forlater ikke forespørsler webtjenesten direkte: de går gjennom en dedikert proxy-komponent som kjører i din egen distribusjon, som begrenser protokollene som er tillatt, løser målets vertsnavn og avviser adresser i private områder. Du kan begrense den ytterligere til et eksplisitt sett med tillatte ressurser. Bare målets URL sendes; ingen prosjektdata følger med forespørselen.
Hvis policyen din krever en utgående tillatelsesliste, tillat bare vertene hvis funksjoner 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, pluss din egen e-postserver og identitetsleverandør. Avvis resten. Ingen andre funksjoner krever utgående tilgang. Der utgående trafikk må inspiseres eller logges sentralt, kan GitHub-, Zotero- og Mendeley-integrasjonene hver routes gjennom en HTTP-proxy ved å sette `GITHUB_SYNC_PROXY_URL` , `MENDELEY_PROXY_URL` og `ZOTERO_PROXY_URL`. Filer som er lenket fra en URL kan ikke begrenses til en vertsliste, siden destinasjonen velges av brukeren på forespørselstidspunktet; begrens den funksjonen gjennom proxy-komponentens egen innstilling for tillatte ressurser, eller la den være deaktivert. ### Er prosjektkompiler isolerte? Ayakaleaf Pro støtter sandkasseisolerte kompileringer. Hver kompilering kjører i en separat container. Sandkassecontainere har ingen nettverkstilgang som standard. Dette reduserer eksponeringen for interne nettverksressurser. Sandkasseisolerte kompileringer krever tilgang til Docker-soklen på verten. Begrens administrasjon av verten til betrodde operatører. ### Kan jeg stole på CI-bygg og containeravbildninger? GitHub Actions bygger og publiserer Ayakaleaf Pro-containeravbildninger. Avbildningene er tilgjengelige fra det offentlige GitHub Container Registry. Avbildninger støtter `amd64` og `arm64`. Docker velger den samsvarende arkitekturen når den henter en avbildning. Ikke bruk `latest` -taggen i produksjon. Fest en eksplisitt versjon, helst en image-digest. Test hver oppgradering i et ikke-produksjonsmiljø. Verifiser avbildningen, konfigurasjonen og integrasjonene før utrulling. ### Er koden åpen kildekode? Ayakaleaf Pro og tilhørende funksjonsrepositorier er offentlig tilgjengelige. Dette lar brukere gjennomgå endringer og spore oppstrømskilder. Offentlig kildekode støtter uavhengig gjennomgang. Den garanterer ikke i seg selv gjenskapbare utgivelsesbygg. Før oppgradering, gå gjennom: * Utgivelses-taggen eller commit-en. * Image-versjonen eller digest-en. * Tredjepartsavhengigheter og lisenskrav. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://ayakaleaf-pro.ayaka.space/on-premises/no/readme/tillit-og-sikkerhet.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.