Skip to main content
Ayakaleaf Pro działa w Twojej infrastrukturze. To Ty kontrolujesz jego dane, dostęp i granice sieci. Ta strona wyjaśnia domyślny model bezpieczeństwa, a także wskazuje Twoje obowiązki operacyjne.

​
Czy Ayakaleaf Pro jest niezawodny i bezpieczny?

Ayakaleaf Pro to samodzielnie hostowane rozszerzenie Overleaf Pro, a nasz kod źródłowy jest dostępny pod adresem ayaka-notes/ayakaleaf-pro. To Twoje wdrożenie decyduje o tym, gdzie działają usługi i gdzie znajdują się dane. Bezpieczeństwo zależy od Twojej konfiguracji i sposobu eksploatacji. Chroń dostęp administracyjny, włącz HTTPS i regularnie twórz kopie zapasowe. Dziękujemy OpenAI za życzliwe wsparcie. Będziemy regularnie używać Codex Security do skanowania naszego repozytorium pod kątem problemów z bezpieczeństwem i publicznie udostępniać wyniki naprawy podatności.

​
Gdzie trafiają moje dane?

Domyślnie dane aplikacji pozostają w obrębie Twojego wdrożenia:
  • MongoDB przechowuje dane użytkowników i projektów.
  • Redis przechowuje pamięć podręczną i dane współpracy w czasie rzeczywistym.
  • Lokalne wolumeny lub magazyn zgodny z S3 przechowują pliki projektów.
Domyślnie udostępniona na zewnątrz jest tylko usługa webowa. Usługi wewnętrzne komunikują się przez sieć Dockera.

​
Czy moje dane będą wysyłane do stron trzecich lub z nich pobierane?

Nic nie opuszcza Twojego wdrożenia, chyba że włączysz funkcję, która tego wymaga. Ayakaleaf Pro nie wysyła telemetrii, analityki użytkowania ani raportów o awariach. Raportowanie błędów i analityka są wyłączone w konfiguracji domyślnej. Kilka funkcji w ogóle nie wykonuje żadnych żądań zewnętrznych. Szablony są przechowywane i serwowane z Twojego własnego wdrożenia. Moduł uruchamiania skryptów Python działa w przeglądarce użytkownika za pośrednictwem WebAssembly, a jego środowisko uruchomieniowe jest serwowane z Twojej własnej usługi webowej, a nie z publicznego CDN, więc kod skryptów i ich wyniki nigdy nie trafiają do sieci. Git Bridge jest dostępny tylko w wewnętrznej sieci Dockera. Pełne wyszukiwanie w projekcie, paleta symboli, śledzenie zmian, historia projektu i panel administracyjny działają w całości lokalnie. Kontenery kompilacji w trybie sandbox są tworzone z wyłączoną siecią. Żądania pozostałych funkcji trafiają do poniższych miejsc docelowych. Każde żądanie pochodzi z usługi webowej:
Funkcje AI są domyślnie wyłączone. Po ich włączeniu czat i sugestie dotyczące błędów LaTeX wysyłają prompty i odpowiedni kontekst projektu do punktu końcowego modelu skonfigurowanego za pomocą AI_BASE_URL. Opcjonalne wyszukiwanie w sieci wysyła zapytania do skonfigurowanej usługi zgodnej z Tavily, a wyszukiwanie w dokumentacji wysyła zapytania do DOCS_MCP_URL (domyślnie: https://docs.overleaf.com/~gitbook/mcp). Wyniki wyszukiwania mogą być dołączane do żądań wysyłanych do dostawcy modelu. Informacje o konfiguracji i ustawieniach dostępnych dla użytkowników znajdziesz w AI Integration.
Integracja z GitHub łączy się z github.com i api.github.com. Jest włączana indywidualnie przez każdego użytkownika poprzez połączenie konta GitHub, a autoryzacja żąda zakresów read:org, repo i workflow. Wypychanie (push) przesyła pełną zawartość plików projektu jako bloby Git, które są następnie składane w drzewa i commity. Integracja wykonuje również operacje na gałęziach, referencjach, porównaniach i scaleniach oraz odczytuje profil połączonego konta, przynależność do organizacji i listę repozytoriów. Treść projektu opuszcza Twoje wdrożenie w obu kierunkach — traktuj połączone konto GitHub jako ścieżkę eksportu dla każdego dołączonego do niego projektu.
Integracja z Zotero łączy się z www.zotero.org w celu autoryzacji i z api.zotero.org w celu pobrania danych biblioteki. Jest włączana indywidualnie przez każdego użytkownika poprzez połączenie konta Zotero. Wysyłane są dane uzgadniania OAuth oraz klucz API użytkownika. Odczyt odbywa się jednokierunkowo: biblioteki bibliograficzne są pobierane w formacie BibTeX i żadna treść projektu nie jest przesyłana.
Integracja z Mendeley łączy się z api.mendeley.com zarówno w celu autoryzacji, jak i pobrania danych biblioteki. Jest włączana indywidualnie przez każdego użytkownika poprzez połączenie konta Mendeley. Uzgadnianie OAuth żąda zakresu all Mendeley — jedynego zakresu oferowanego przez jego API — ale Ayakaleaf wykonuje wyłącznie odczyty: biblioteki bibliograficzne i biblioteki grupowe są pobierane w formacie BibTeX i żadna treść projektu nie jest przesyłana. Tokeny dostępu są odświeżane automatycznie; gdy Mendeley cofnie uprawnienie, zapisane dane uwierzytelniające są usuwane, a użytkownik jest proszony o ponowne połączenie konta.
Strony dokumentacji są pobierane z https://learnwiki.overleaf.com, co można skonfigurować za pomocą WIKI_URL. Żądania wykonuje usługa webowa, a nie przeglądarka użytkownika, więc nadrzędne wiki widzi Twój serwer, a nigdy adresy Twoich użytkowników. Wysyłany jest tylko tytuł żądanej strony, a odpowiedzi są buforowane na dysku. Jeśli wychodzący ruch związany z dokumentacją jest niedopuszczalny, wskaż w WIKI_URL własny serwer lustrzany lub zablokuj to miejsce docelowe.
Wysyłka e-maili łączy się z dowolnym skonfigurowanym przez Ciebie serwerem SMTP lub API pocztowym; nie ma ustawienia domyślnego. Adresy odbiorców i treść wiadomości opuszczają Twoje wdrożenie, w tym linki do resetowania hasła i zaproszenia.
Dwie opcjonalne weryfikacje są domyślnie wyłączone. Sprawdzanie, czy hasło nie wyciekło, jest nieaktywne, dopóki nie zostanie ustawione HAVE_I_BEEN_PWNED_ENABLED; po włączeniu wysyła pierwsze znaki skrótu SHA-1 hasła do api.pwnedpasswords.com, nigdy samo hasło. Weryfikacja CAPTCHA jest nieaktywna, dopóki nie zostanie skonfigurowany klucz witryny reCAPTCHA; gdy jest aktywna, łączy się z www.google.com.
Logowanie jednokrotne (SSO) łączy się wyłącznie z dostarczonym przez Ciebie dostawcą tożsamości, a to, jakie dane są przesyłane, zależy od protokołu. W przypadku LDAP usługa webowa łączy się bezpośrednio z Twoim katalogiem: wykonuje bind przy użyciu skonfigurowanego konta usługi, wyszukuje w ramach zdefiniowanej bazy, filtra i listy atrybutów oraz weryfikuje hasło wprowadzone w formularzu logowania względem katalogu, więc nazwa użytkownika i hasło trafiają do serwera katalogowego. Włączenie kontaktów opartych na katalogu powoduje dodatkowe wyszukiwanie w celu wypełnienia listy kontaktów. W przypadku OIDC usługa webowa wymienia kod autoryzacyjny w Twoim punkcie końcowym tokenów, a następnie wywołuje punkt końcowy informacji o użytkowniku, domyślnie żądając zakresów openid profile email; można to skonfigurować za pomocą OVERLEAF_OIDC_SCOPE. W przypadku SAML żądanie uwierzytelnienia trafia do dostawcy tożsamości przez przeglądarkę użytkownika, a nie przez bezpośrednie połączenie z serwera. We wszystkich trzech przypadkach imię i nazwisko oraz adres e-mail użytkownika są otrzymywane od dostawcy, a nie do niego wysyłane, a następnie zapisywane w lokalnym rekordzie użytkownika.
Dane uwierzytelniające usług zewnętrznych — tokeny OAuth i klucze API — są przechowywane w MongoDB w rekordzie użytkownika, zaszyfrowane algorytmem AES-256-CTR z solą i wektorem inicjalizacyjnym unikalnymi dla każdego rekordu. Nigdy nie są przechowywane jako tekst jawny ani zapisywane w logach. Klucz szyfrujący pochodzi z ${PROVIDER}_CIPHER_PASSWORD, jeśli jest ustawiony (np. dla Zotero i Mendeley); w przeciwnym razie jest generowany przy pierwszym użyciu i zapisywany w wolumenie danych z uprawnieniami tylko dla właściciela. Twórz kopię zapasową tego klucza razem z wolumenem danych: jeśli zostanie utracony, zapisanych danych uwierzytelniających nie będzie można odszyfrować i każdy użytkownik będzie musiał ponownie połączyć swoje konta.
Pliki połączone z adresu URL są pobierane przez Twoje wdrożenie w imieniu użytkownika, więc miejscem docelowym jest dowolny adres podany przez użytkownika. Pliki połączone z URL są wyłączone, dopóki nie dodasz url do ENABLED_LINKED_FILE_TYPES, a konfiguracja domyślna tego nie zawiera. Zewnętrzne importy ZIP i TeX przez API Open in Overleaf również korzystają z tego samego komponentu linked-url-proxy. Żądania bezpośrednie rozwiązują nazwę hosta docelowego i odrzucają zastrzeżone zakresy sieci, z uwzględnieniem skonfigurowanych wyjątków dozwolonych zasobów. Przy skonfigurowanym OVERLEAF_LINKED_URL_OUTBOUND_PROXY to serwer proxy ruchu wychodzącego rozwiązuje nazwy hostów, więc musi on samodzielnie egzekwować ograniczenia dotyczące sieci wewnętrznej; kontrole sieciowe aplikacji dotyczą wtedy tylko adresów URL zawierających adresy IP. Szczegóły znajdziesz w External URL — Outbound Proxy. Żądania te pobierają podany adres URL, a nie przesyłają plików projektu.
Jeśli Twoja polityka wymaga listy dozwolonych połączeń wychodzących, zezwól tylko na hosty powiązane z włączonymi funkcjami — github.com i api.github.com dla GitHub, www.zotero.org i api.zotero.org dla Zotero, api.mendeley.com dla Mendeley, learnwiki.overleaf.com lub własny WIKI_URL dla dokumentacji, api.pwnedpasswords.com dla sprawdzania haseł, www.google.com dla CAPTCHA, a także własny serwer pocztowy i dostawcę tożsamości. Jeśli włączone są funkcje AI lub wyszukiwanie, zezwól również na skonfigurowane punkty końcowe modelu, wyszukiwania w sieci i MCP dokumentacji. Blokuj miejsca docelowe, które nie są wymagane przez włączone funkcje. Jeśli ruch wychodzący musi być centralnie kontrolowany lub logowany, integracje z GitHub, Zotero i Mendeley można przekierować przez serwer proxy HTTP, ustawiając odpowiednio GITHUB_SYNC_PROXY_URL, MENDELEY_PROXY_URL i ZOTERO_PROXY_URL. Pobieranie plików połączonych z URL i importy zdalne mogą korzystać z OVERLEAF_LINKED_URL_OUTBOUND_PROXY. Plików połączonych z adresu URL nie można ograniczyć do listy hostów, ponieważ miejsce docelowe wybiera użytkownik w momencie żądania; ogranicz tę funkcję za pomocą ustawienia dozwolonych zasobów w samym komponencie proxy lub pozostaw ją wyłączoną.
Czy w przypadku wdrożenia Ayakaleaf Pro z włączonym magazynem s3.md dane przechowywane w S3 są szyfrowane?Nie. Dane nie są szyfrowane. Wszystkie fragmenty historii, pliki szablonów, pliki PDF i inne pliki są przechowywane jako tekst jawny. Jeśli korzystasz z zewnętrznego magazynu S3 innej firmy, zwróć szczególną uwagę na bezpieczeństwo i prywatność danych.

​
Czy kompilacje projektów są izolowane?

Ayakaleaf Pro obsługuje kompilacje w trybie sandbox. Każda kompilacja odbywa się w osobnym kontenerze. Kontenery sandbox domyślnie nie mają dostępu do sieci. Ogranicza to narażenie zasobów sieci wewnętrznej. Kompilacje w trybie sandbox wymagają dostępu do gniazda Dockera hosta. Ogranicz administrację hostem do zaufanych operatorów.

​
Czy mogę ufać buildom CI i obrazom kontenerów?

GitHub Actions buduje i publikuje obrazy kontenerów Ayakaleaf Pro. Obrazy są dostępne w publicznym GitHub Container Registry. Obrazy obsługują architektury amd64 i arm64. Docker podczas pobierania obrazu wybiera odpowiednią architekturę. Nie używaj tagu latest w środowisku produkcyjnym. Przypnij konkretną wersję, najlepiej skrót (digest) obrazu. Testuj każdą aktualizację w środowisku nieprodukcyjnym. Przed wdrożeniem zweryfikuj obraz, konfigurację i integracje.

​
Czy kod jest open source?

Ayakaleaf Pro i powiązane repozytoria funkcji są publicznie dostępne. Dzięki temu użytkownicy mogą przeglądać zmiany i śledzić źródła nadrzędne. Publiczny kod źródłowy umożliwia niezależny przegląd. Sam w sobie nie gwarantuje jednak odtwarzalności buildów wydań. Przed aktualizacją sprawdź:
  • Tag wydania lub commit.
  • Wersję lub skrót (digest) obrazu.
  • Zależności zewnętrzne i wymagania licencyjne.
Ostatnia modyfikacja 5 października 2026