Skip to main content
Ayakaleaf Pro běží ve vaší infrastruktuře. Data, přístup i hranice sítě máte pod kontrolou vy. Tato stránka vysvětluje výchozí bezpečnostní model a také uvádí vaše provozní odpovědnosti.

​
Je Ayakaleaf Pro spolehlivý a bezpečný?

Ayakaleaf Pro je self-hosted rozšíření Overleaf Pro a náš zdrojový kód je dostupný na ayaka-notes/ayakaleaf-pro. O tom, kde služby běží a kde jsou uložena data, rozhoduje vaše nasazení. Zabezpečení závisí na vaší konfiguraci a provozu. Chraňte administrátorský přístup, povolte HTTPS a udržujte zálohy. Děkujeme společnosti OpenAI za laskavou podporu. Náš repozitář budeme pravidelně kontrolovat na bezpečnostní problémy pomocí Codex Security a výsledky oprav zranitelností budeme veřejně sdílet.

​
Kam putují moje data?

Ve výchozím nastavení zůstávají data aplikace uvnitř vašeho nasazení:
  • MongoDB ukládá data uživatelů a projektů.
  • Redis ukládá mezipaměť a data pro spolupráci v reálném čase.
  • Soubory projektů jsou uloženy v lokálních svazcích nebo v úložišti kompatibilním s S3.
Ve výchozím stavu je zpřístupněna pouze webová služba. Interní služby spolu komunikují přes síť Dockeru.

​
Budou moje data odesílána třetím stranám nebo od nich získávána?

Nic neopustí vaše nasazení, pokud nepovolíte funkci, která to vyžaduje. Ayakaleaf Pro neodesílá žádnou telemetrii, žádné analýzy používání ani žádná hlášení o pádech. Hlášení chyb a analytika jsou ve výchozí konfiguraci vypnuté. Několik funkcí nikdy neprovádí žádné externí požadavky. Šablony jsou uloženy a poskytovány z vašeho vlastního nasazení. Spouštění skriptů v Pythonu probíhá v prohlížeči uživatele pomocí WebAssembly a jeho runtime je poskytován z vaší vlastní webové služby, nikoli z veřejného CDN, takže kód skriptů ani jejich výstup se nikdy nedostanou do sítě. Git Bridge je dostupný pouze ve vnitřní síti Dockeru. Fulltextové vyhledávání v projektu, paleta symbolů, sledování změn, historie projektu a administrátorský panel fungují zcela lokálně. Kontejnery pro kompilaci v sandboxu se vytvářejí s vypnutou sítí. Požadavky zbývajících funkcí směřují na následující cíle. Každý požadavek vychází z webové služby:
Funkce AI jsou ve výchozím stavu vypnuté. Po jejich povolení odesílají chat a návrhy oprav chyb LaTeXu prompty a relevantní kontext projektu na endpoint modelu nakonfigurovaný pomocí AI_BASE_URL. Volitelné webové vyhledávání odesílá dotazy na nakonfigurovanou službu kompatibilní s Tavily a vyhledávání v dokumentaci odesílá dotazy na DOCS_MCP_URL (výchozí: https://docs.overleaf.com/~gitbook/mcp). Výsledky vyhledávání mohou být zahrnuty do požadavků na poskytovatele modelu. Konfiguraci a nastavení pro uživatele najdete v AI Integration.
Integrace s GitHubem komunikuje s github.com a api.github.com. Povoluje se pro každého uživatele zvlášť propojením účtu GitHub a autorizace požaduje oprávnění read:org, repo a workflow. Při odeslání (push) se nahrává úplný obsah souborů projektu jako Git bloby, ze kterých se pak sestavují stromy a commity. Provádí také operace s větvemi, referencemi, porovnáním a slučováním a čte profil propojeného účtu, členství v organizacích a seznam repozitářů. Obsah projektu opouští vaše nasazení oběma směry — propojený účet GitHub považujte za exportní cestu pro každý projekt, který je k němu připojen.
Integrace se Zoterem komunikuje s www.zotero.org kvůli autorizaci a s api.zotero.org kvůli datům knihovny. Povoluje se pro každého uživatele zvlášť propojením účtu Zotero. Odesílá se OAuth handshake a API klíč uživatele. Čtení je jednosměrné: knihovny citací se stahují jako BibTeX a žádný obsah projektu se nenahrává.
Integrace s Mendeley komunikuje s api.mendeley.com kvůli autorizaci i datům knihovny. Povoluje se pro každého uživatele zvlášť propojením účtu Mendeley. OAuth handshake požaduje oprávnění all od Mendeley — jediné, které jeho API nabízí —, Ayakaleaf však provádí pouze čtení: knihovny citací a skupinové knihovny se stahují jako BibTeX a žádný obsah projektu se nenahrává. Přístupové tokeny se obnovují automaticky; když Mendeley oprávnění odvolá, uložené přihlašovací údaje se zahodí a uživatel je vyzván k opětovnému propojení účtu.
Stránky dokumentace se načítají z https://learnwiki.overleaf.com, což lze nastavit pomocí WIKI_URL. Požadavky provádí webová služba, nikoli prohlížeč uživatele, takže upstreamová wiki vidí váš server a nikdy adresy vašich uživatelů. Odesílá se pouze název požadované stránky a odpovědi se ukládají do mezipaměti na disku. Pokud odchozí provoz dokumentace není přijatelný, nasměrujte WIKI_URL na vlastní zrcadlo nebo cíl zablokujte.
Doručování e-mailů komunikuje s jakýmkoli SMTP serverem nebo poštovním API, které nakonfigurujete; žádný výchozí neexistuje. Adresy příjemců a obsah zpráv opouštějí vaše nasazení, včetně odkazů pro obnovení hesla a pozvánek.
Dvě volitelné kontroly jsou ve výchozím stavu vypnuté. Kontrola kompromitovaných hesel je neaktivní, dokud není nastavena HAVE_I_BEEN_PWNED_ENABLED; po povolení odesílá na api.pwnedpasswords.com prvních několik znaků hashe SHA-1 hesla, nikdy heslo samotné. Ověření CAPTCHA je neaktivní, dokud není nakonfigurován klíč webu reCAPTCHA, a když je aktivní, komunikuje s www.google.com.
Jednotné přihlášení komunikuje pouze s poskytovatelem identity, kterého zadáte, a co se k němu přenáší, závisí na protokolu. U LDAP se webová služba připojuje přímo k vašemu adresáři: přihlásí se (bind) pomocí nakonfigurovaného servisního účtu, vyhledává pod vámi definovanou bází, filtrem a seznamem atributů a ověřuje heslo zadané v přihlašovacím formuláři vůči vašemu adresáři, takže uživatelské jméno a heslo se dostanou na adresářový server. Povolení kontaktů z adresáře vyvolá další vyhledávání pro naplnění seznamu kontaktů. U OIDC webová služba vymění autorizační kód na vašem token endpointu a poté zavolá váš endpoint s informacemi o uživateli, přičemž ve výchozím stavu požaduje oprávnění openid profile email; to lze nastavit pomocí OVERLEAF_OIDC_SCOPE. U SAML putuje požadavek na ověření přes prohlížeč uživatele k poskytovateli identity, nikoli přes přímé spojení serveru. Ve všech třech případech jméno a e-mailová adresa uživatele od poskytovatele přicházejí, nikoli k němu odcházejí, a poté se uloží do lokálního záznamu uživatele.
Přihlašovací údaje třetích stran — tokeny OAuth a API klíče — jsou uloženy v MongoDB v záznamu uživatele, zašifrované pomocí AES-256-CTR se solí a inicializačním vektorem pro každý záznam. Nikdy se neukládají jako prostý text a nikdy se nezapisují do logů. Šifrovací klíč pochází z ${PROVIDER}_CIPHER_PASSWORD, je-li nastavena (např. pro Zotero a Mendeley); jinak se vygeneruje při prvním použití a uloží se do vašeho datového svazku s oprávněními pouze pro vlastníka. Tento klíč zálohujte spolu s datovým svazkem: pokud ho ztratíte, uložené přihlašovací údaje nepůjde dešifrovat a všichni uživatelé budou muset své účty propojit znovu.
Soubory propojené z URL stahuje vaše nasazení jménem uživatele, takže cílem je jakákoli adresa, kterou uživatel zadá. Soubory propojené z URL jsou vypnuté, dokud nepřidáte url do ENABLED_LINKED_FILE_TYPES, a výchozí konfigurace ho neobsahuje. Externí importy ZIP a TeX přes Open in Overleaf API také používají stejnou komponentu linked-url-proxy. Přímé požadavky přeloží cílový název hostitele a odmítnou zakázané síťové rozsahy, s výjimkou nakonfigurovaných povolených prostředků. Pokud je nakonfigurována OVERLEAF_LINKED_URL_OUTBOUND_PROXY, překládá názvy hostitelů odchozí proxy, takže musí omezení vnitřní sítě vynucovat sama; síťové kontroly aplikace se pak uplatní jen u URL obsahujících IP adresy. Podrobnosti viz External URL — Outbound Proxy. Tyto požadavky stahují zadanou URL, nenahrávají soubory projektu.
Pokud vaše zásady vyžadují seznam povolených odchozích cílů, povolte pouze hostitele funkcí, které jste zapnuli — github.com a api.github.com pro GitHub, www.zotero.org a api.zotero.org pro Zotero, api.mendeley.com pro Mendeley, learnwiki.overleaf.com nebo vlastní WIKI_URL pro dokumentaci, api.pwnedpasswords.com pro kontrolu hesel, www.google.com pro CAPTCHA a dále svůj poštovní server a poskytovatele identity. Pokud jsou povoleny funkce AI nebo vyhledávání, povolte také nakonfigurované endpointy modelu, webového vyhledávání a MCP dokumentace. Cíle, které vaše povolené funkce nevyžadují, zakažte. Pokud musí být odchozí provoz centrálně kontrolován nebo logován, lze integrace s GitHubem, Zoterem a Mendeley směrovat přes HTTP proxy nastavením GITHUB_SYNC_PROXY_URL, MENDELEY_PROXY_URL a ZOTERO_PROXY_URL. Stahování propojených URL a vzdálené importy mohou používat OVERLEAF_LINKED_URL_OUTBOUND_PROXY. Soubory propojené z URL nelze omezit na seznam hostitelů, protože cíl volí uživatel v okamžiku požadavku; tuto funkci omezte pomocí nastavení povolených prostředků samotné komponenty proxy, nebo ji ponechte vypnutou.
Pokud nasadíte Ayakaleaf Pro s povoleným úložištěm s3.md, jsou data uložená v S3 šifrovaná?Ne. Data nejsou šifrována. Všechny bloky historie, soubory šablon, PDF a další soubory jsou uloženy jako prostý text. Pokud používáte externí úložiště S3 třetí strany, věnujte prosím zvýšenou pozornost bezpečnosti a ochraně dat.

​
Jsou kompilace projektů izolované?

Ayakaleaf Pro podporuje kompilace v sandboxu. Každá kompilace běží v samostatném kontejneru. Kontejnery sandboxu ve výchozím stavu nemají přístup k síti. To snižuje vystavení prostředkům vnitřní sítě. Kompilace v sandboxu vyžadují přístup k socketu Dockeru na hostiteli. Správu hostitele svěřte pouze důvěryhodným operátorům.

​
Mohu důvěřovat sestavením z CI a image kontejnerů?

Image kontejnerů Ayakaleaf Pro sestavuje a publikuje GitHub Actions. Image jsou dostupné z veřejného registru GitHub Container Registry. Image podporují amd64 a arm64. Docker při stahování image automaticky zvolí odpovídající architekturu. V produkci nepoužívejte tag latest. Připněte konkrétní verzi, nejlépe digest image. Každý upgrade otestujte v neprodukčním prostředí. Před nasazením ověřte image, konfiguraci a integrace.

​
Je kód open source?

Ayakaleaf Pro a související repozitáře funkcí jsou veřejně dostupné. Uživatelé tak mohou kontrolovat změny a dohledat upstreamové zdroje. Veřejný zdrojový kód umožňuje nezávislou kontrolu. Sám o sobě však nezaručuje reprodukovatelná sestavení vydání. Před upgradem zkontrolujte:
  • Tag nebo commit vydání.
  • Verzi nebo digest image.
  • Závislosti třetích stran a licenční požadavky.
Naposledy změněno 5. října 2026