Scenariusz wygląda zwykle tak. Masz świeżutkie n8n, masz pomysł na automatyzację z Gmailem, Kalendarzem, Dyskiem albo Arkuszami. Zakładasz dane logowania przez OAuth i… Google wywala błąd o niezaufanej domenie. Zanim w ogóle zdążysz się zalogować.

Od razu uspokajam: n8n się nie zepsuło. Chodzi o to, jak Google patrzy na domenę, pod którą stoi Twoja instancja.

Skąd się bierze ten błąd#

n8n postawione na Mikrusie przez n8n_install (skrypt z NOOBS-a) dostaje domyślnie automatyczną subdomenę w domenie wykr.es, np. emil100-20100.wykr.es. Kiedy zakładasz w n8n dane logowania OAuth do którejś usługi Google, n8n samo buduje z tej domeny adres przekierowania (redirect URI), mniej więcej taki:

https://emil100-20100.wykr.es/rest/oauth2-credential/callback

Ten adres wklejasz potem w Google Cloud Console jako “Authorized redirect URI”. I tu zaczynają się schody.

Google przyjmie jako autoryzowany redirect URI tylko domenę, której jesteś właścicielem i którą zweryfikowałeś w Google Search Console (rekordem TXT w DNS albo plikiem weryfikacyjnym). A wykr.es należy do nas i dzielą ją tysiące instancji różnych ludzi. Do jej DNS-u nie masz i nie dostaniesz dostępu, więc zweryfikować się jej nie da. Google odrzuca taki adres, zanim w ogóle dojdzie do logowania.

Rozwiązanie: własna domena zamiast wykr.es#

Obejścia nie ma. Jedyne wyjście to postawić n8n pod domeną, która naprawdę jest Twoja i którą możesz zweryfikować.

Jeśli n8n stawiałeś przez NOOBS-a, przełączysz je na własną domenę tą samą komendą co przy instalacji, tylko tym razem z domeną jako drugim argumentem. Port zostaw taki sam jak wcześniej, żeby nie stracić dostępu do dotychczasowych danych:

n8n_install 20100 twoja-domena.pl

Kontener zostanie podmieniony, ale dane - workflowy, dane logowania, historia wykonań - przetrwają bez szwanku. Leżą w katalogu ~/.n8n, który jest tylko podpinany do nowego kontenera, a nie tworzony od zera.

Potem kierujesz rekord DNS twoja-domena.pl na adres IP swojego Mikrusa, w panelu domeny albo w Cloudflare.

Zaznaczam, bo to częste nieporozumienie: ustawienie domeny w n8n niczego w DNS nie tworzy ani nie konfiguruje. To robisz osobno, sam. A jeśli jesteś na Cloudflare, sprawdź jeszcze, czy ruch rzeczywiście trafia na właściwy port Twojego Mikrusa.

Weryfikacja domeny w Google#

Z własną domeną wreszcie da się przejść przez pełną weryfikację w Google:

  1. W Google Search Console dodajesz domenę jako właściwość i ją weryfikujesz. Najprościej rekordem TXT w DNS - w panelu domeny albo w Cloudflare to kwestia kilku minut.
  2. W Google Cloud Console, w projekcie ze skonfigurowanym ekranem zgody OAuth, dopisujesz tę domenę do Authorized domains.
  3. W ustawieniach swojego OAuth Client ID (typ “Web application”) wklejasz nowy redirect URI, tym razem z własną domeną:
https://twoja-domena.pl/rest/oauth2-credential/callback

I dopiero teraz Google łaskawie pozwoli zapisać ten adres jako autoryzowany. Domena jest zweryfikowana, więc wszystko się zgadza.

Najczęstsze błędy#

Upór przy redirect URI z wykr.es. Google Cloud Console odrzuci go już przy zapisywaniu konfiguracji klienta OAuth. Bez zmiany domeny się nie obejdzie, choćbyś próbował na sto sposobów.

Domena zmieniona w n8n, a DNS nie. Jeśli twoja-domena.pl nie wskazuje jeszcze na Twojego Mikrusa, Google po zalogowaniu przekieruje Cię poprawnie, ale przeglądarka nie trafi do n8n i proces się nie domknie.

Weryfikacja w Search Console nie tej właściwości, co trzeba. Stawiasz n8n na subdomenie, np. n8n.twoja-domena.pl? Zweryfikuj dokładnie tę subdomenę albo całą domenę na poziomie DNS. Weryfikacja domeny “z góry” obejmuje wszystkie subdomeny, a weryfikacja pojedynczego adresu URL już nie.

Po tej przeprowadzce logowanie przez Google powinno przejść gładko, bez żadnych ostrzeżeń. Cena to własna domena zamiast darmowej subdomeny wykr.es. Ale bez tego integracja z usługami Google po prostu nie ruszy.