Dotyczy produktów: Symfonia eDokumenty (Ready OnPremise)
Wprowadzenie:
Domyślnie Symfonia eDokumenty korzysta z gotowej aplikacji Azure AD — sekcja [azure_ready_] w pliku oauth2.toml_default — wspólnej dla wszystkich klientów Ready-OS. Gdy chcesz logować się własną aplikacją Microsoft — własny clientId i clientSecret — zarejestruj własną aplikację w Azure/Entra ID i podmień dane w konfiguracji.
Rejestracja aplikacji w Azure Portal
- Zaloguj się na portal.azure.com kontem z uprawnieniami administratora w tenancie Entra ID — Azure AD.
- Przejdź do: Microsoft Entra ID → App registrations → New registration.
- Wypełnij formularz:
- Name: np. eDokumenty OAuth
-
Supported account types:
- Accounts in this organizational directory only — logowanie tylko dla kont z Twojej firmy;
- Accounts in any organizational directory and personal Microsoft accounts — szerszy zakres, jeśli potrzebne logowanie dowolnym kontem Microsoft
-
Redirect URI — typ: Web: adres, pod którym Twoja instalacja eDokumenty obsługuje callback OAuth, np.:
https://twoja-domena.pl/oauth.php/login_callback
- Kliknij Register.
Pobranie Client ID
Na stronie Overview nowo utworzonej aplikacji skopiuj wartość Application (client) ID. To jest Twój nowy clientId.
Wygenerowanie Client Secret
- Przejdź do Certificates & secrets → Client secrets → New client secret.
- Podaj opis i okres wygaśnięcia — np. 12/24 miesiące.
- Kliknij Add.
- Skopiuj wartość — Value — natychmiast po odświeżeniu strony, nie odczytasz jej ponownie.
- To jest Twój nowy clientSecret.
Ważne!
- Nie pomyl pól na stronie Certificates & secrets.
- Value — to jest faktyczny clientSecret, ten ciąg wklejasz do oauth2.toml. Widoczny tylko raz, zaraz po utworzeniu — potem zamaskowany — •••••••• — i nieodzyskiwalny.
- Secret ID — to tylko wewnętrzny identyfikator GUID danego sekretu, do zarządzania/rotacji w Azure Portal. To nie jest clientSecret — wklejenie tej wartości do konfiguracji nie zadziała.
Uprawnienia API — opcjonalnie
W API permissions sprawdź, czy dodane są uprawnienia Microsoft Graph: openid, profile, email — zwykle są domyślnie przy rejestracji. Jeśli logowanie wymaga dodatkowych danych — np. dostęp do kalendarza, maili — dodaj odpowiednie scope'y.
Scope'y wymagane do pobierania/wysyłania maili — IMAP/SMTP. Dla integracji eDokumenty korzystającej z protokołów IMAP/SMTP z OAuth2 (nie Graph API) potwierdzono, że wymagany jest cały poniższy zestaw. Żaden z nich nie jest zbędny w tym przypadku:
- openid — podstawowe uwierzytelnienie OIDC
- profile — podstawowe dane profilu użytkownika — dodawane domyślnie przy rejestracji
- email — adres e-mail użytkownika — dodawane domyślnie przy rejestracji
- offline_access — refresh token, dostęp w tle bez ponownego logowania
- IMAP.AccessAsUser.All — odczyt skrzynki przez IMAP — OAuth2/XOAUTH2
- SMTP.Send — wysyłka maili przez SMTP — OAuth2
- Mail.Send — wysyłka maili przez Microsoft Graph API
Podmiana konfiguracji w eDokumenty
- Skopiuj plik oauth2.toml_default do oauth2.toml (bez przyrostka _default) w tym samym katalogu konfiguracyjnym. To plik, który faktycznie wczytuje aplikacja i który nadpisuje wartości domyślne. Domyślnie jest w /home/edokumenty/etc.
-
W sekcji odpowiadającej Microsoft wpisz swoje dane — wybierz zakładkę odpowiadającą typowi Twojej aplikacji:
- [azure_ready_]
- wellknownUrl = "https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration"
- redirectUri = "https://twoja-domena.pl/oauth.php/login_callback"
- clientId = "TWÓJ-CLIENT-ID"
- clientSecret= "TWÓJ-CLIENT-SECRET-VALUE"
Tenant ID znajdziesz w Azure Portal: Microsoft Entra ID → Overview — pole Tenant ID — lub App registrations → [Twoja aplikacja] → Overview (pole Directory (tenant) ID).
Pozostawienie common zadziała tylko dla aplikacji multi-tenant.
Jeśli aplikacja jest single-tenant (ustawienie "Accounts in this organizational directory only"), trzeba zamienić common w wellknownUrl na swój Tenant ID:
wellknownUrl = "https://login.microsoftonline.com/TWÓJ-TENANT-ID/v2.0/.well-known/openid-configuration" - Zapisz plik.
Przekompilowanie konfiguracji
- Przejdź do katalogu /home/edokumenty.
-
Wykonaj:
./ready-cli config:compile
Ponowna autoryzacja kont pocztowych w eDokumenty
Gdy zmienisz konfigurację — clientId/clientSecret/scope — i przekompilujesz, same ustawienia w oauth2.toml nie wystarczą. Ponownie przejdź proces autoryzacji dla każdego konta pocztowego skonfigurowanego w systemie:
- Zaloguj się do Symfonia eDokumenty.
- Przejdź do konfiguracji konta pocztowego.
- Otwórz konfigurację konta pocztowego i kliknij OK, aby przejść przez kreator. Pojawi się ekran logowania/zgody Microsoft, który przeklikaj, żeby konto otrzymało nowe poświadczenia — token — zgodne z nową konfiguracją aplikacji.
- Czynność powtórz dla każdego konta pocztowego skonfigurowanego w systemie. Zmiana konfiguracji aplikacji w Azure/ oauth2.toml nie odnawia automatycznie poświadczeń już podłączonych kont.
Ważne!
Bez tego kroku konta pocztowe nadal będą działać na starych tokenach/poświadczeniach — lub przestaną działać, jeśli stara aplikacja/scope zostały wyłączone — nawet jeśli konfiguracja systemowa jest już poprawna.
Uwagi
- redirectUri w Azure Portal musi być identyczny — łącznie z protokołem i ścieżką — z tym w pliku oauth2.toml. Inaczej logowanie zwróci błąd redirect_uri_mismatch.
- Jeśli nazwa sekcji azure_ready_ jest sztywno wymagana przez kod eDokumenty, nie zmieniaj jej nazwy — zmieniaj tylko wartości pól. Zweryfikuj to w dokumentacji dostawcy lub z zespołem wsparcia Symfonii, jeśli chcesz dodać dodatkową, niezależną sekcję.
- Client secret ma datę wygaśnięcia. Pamiętaj o jego odnowieniu przed upływem terminu, inaczej logowanie przestanie działać.