Co powoduje, że dostęp do sieci działa, a synchronizacja aplikacji mobilnej nie?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

What Causes Web Access to Work While Mobile App Sync Fails? - Zima Store Online

Dostęp przez przeglądarkę może działać, podczas gdy synchronizacja mobilna zawodzi, ponieważ aplikacja używa różnych interfejsów API, zasad zaufania, tokenów i zachowań sieci w tle.

Przeglądarka może załadować stronę logowania przez zwykłe HTTPS, podczas gdy aplikacja mobilna wywołuje punkty końcowe WebDAV, REST, file-token, powiadomień, chunked-upload lub background-sync, które korzystają z innych tras proxy i kontroli certyfikatów. Diagnoza powinna uchwycić dokładne nieudane żądanie aplikacji, porównać je ze ścieżką przeglądarki oraz osobno przetestować TLS, generowanie URL, tokeny, uprawnienia mobilne i warunki sieciowe.

Określ, która operacja mobilna zawodzi

Oddziel logowanie, listowanie plików, pobieranie, wysyłanie, automatyczne wysyłanie, synchronizację w tle, podgląd, powiadomienia i udostępnianie. Zapisz wersję aplikacji, system operacyjny, sieć, błąd, znacznik czasu oraz wpis w logu serwera dla jednej nieudanej akcji.

Przypadek Seafile pokazał, że przeglądarka działała bez zarzutu, podczas gdy aplikacja mobilna zawiodła na nazwach plików ze spacjami, ponieważ aplikacja używała innej ścieżki API plików, którą proxy odrzucił.

Jeśli zawodzi tylko jedna operacja, nie reinstaluj całego serwera. Najpierw dopasuj punkt końcowy i metodę, które zawodzą; działający panel kontrolny dowodzi, że ani przesyłanie WebDAV, ani pobieranie tokenów mobilnych nie działają.

Przetestuj punkt końcowy aplikacji poza interfejsem przeglądarki

Znajdź udokumentowany URL synchronizacji, WebDAV, API lub serwera plików używany przez klienta mobilnego. Przetestuj ten punkt końcowy bezpośrednio za pomocą odpowiedniego klienta lub narzędzia do żądań, zachowując tę samą nazwę hosta i uwierzytelnianie.

Raport Nextcloud wyjaśnia, że listowanie plików i automatyczne wysyłanie mogą używać innych URL niż API aktywności i powiadomień, więc błąd konfiguracji URL API może dotyczyć tylko części aplikacji.

Jeśli punkt końcowy API zwraca 404, 405, 400 lub przekierowanie do hosta wewnętrznego, sprawdź trasowanie proxy i bazowe URL aplikacji. Jeśli działa poza aplikacją, kontynuuj testy zaufania TLS, tokenów aplikacji i polityki systemu operacyjnego mobilnego.

Porównaj zaufanie TLS mobilne z zaufaniem przeglądarki

Sprawdź pełny łańcuch certyfikatów, nazwę hosta, datę ważności, certyfikaty pośrednie oraz czy aplikacja łączy się przez IPv4 czy IPv6. Przeglądarka może buforować certyfikat pośredni lub pozwalać na wyjątek użytkownika, którego aplikacja mobilna nie udostępnia.

Przypadek Joplin na urządzeniach mobilnych pokazuje, że WebDAV działa na desktopie, podczas gdy na mobilnym iOS odrzucał zwykły HTTP lub nieufny certyfikat, co dowodzi, że polityka TLS mobilna może różnić się od zachowania przeglądarki.

Używaj publicznie zaufanego certyfikatu lub poprawnie zainstalowanego prywatnego CA zamiast wyłączać walidację. Testuj dokładną nazwę hosta synchronizacji, a nie prywatny adres IP, który nie jest objęty tożsamością certyfikatu.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Sprawdź trasy proxy, rozmiar żądania i kodowanie

Porównaj logi proxy dla jednej akcji w przeglądarce i jednej synchronizacji mobilnej. Zapisz metodę, ścieżkę, rozmiar żądania, status, upstream, timeout oraz wszelkie reguły bezpieczeństwa blokujące zakodowane URL, metody WebDAV lub przesyłanie w kawałkach.

Aplikacje mobilne mogą używać PROPFIND, PUT, tokenizowanych URL do pobierania, zakresów lub punktów końcowych chunk, których normalny interfejs webowy nie używa. Proxy, które zezwala na ruch GET i POST z przeglądarki, może nadal odrzucać te metody lub ścieżki.

Dodaj tylko wymagane trasy, metody, limity i timeouty. Nie wyłączaj całego bezpieczeństwa proxy, bo jedno żądanie mobilne zawodzi; odtwórz dokładne żądanie i zweryfikuj wąską poprawkę.

Odśwież tokeny aplikacji i kanoniczne URL serwera

Porównaj URL serwera zapisany w aplikacji z aktualnym publicznym lub wewnętrznym kanonicznym URL. Cofnij i utwórz ponownie jedno hasło lub token specyficzny dla aplikacji zamiast najpierw zmieniać główne hasło konta.

Klienci mobilni mogą zachować stary port, HTTP URL, adres wewnętrzny, wygasły token lub poprzednią ścieżkę reverse-proxy po migracji serwera. Przeglądarka może przekierować poprawnie, podczas gdy klient synchronizacji nadal wywołuje przestarzały punkt końcowy.

Usuń konto tylko z jednego urządzenia testowego po wyeksportowaniu lub zabezpieczeniu niesynchronizowanych danych mobilnych. Dodaj je ponownie, używając kanonicznej domeny HTTPS i potwierdź, że serwer wydaje nowy token przed testowaniem wysyłania i pobierania.

Przetestuj ograniczenia tła i sieci mobilnej

Uruchom synchronizację ręczną na pierwszym planie, następnie zablokuj ekran i przetestuj zachowanie w tle. Sprawdź optymalizację baterii, dane w tle, uprawnienia do sieci lokalnej, uprawnienia komórkowe, VPN, Prywatny DNS oraz zasady przesyłania tylko przez Wi-Fi.

Artykuł ZimaSpace o tym, dlaczego ścieżki zdalnej prywatnej chmury różnią się, pomaga oddzielić błąd ścieżki aplikacji od podstawowego wyniku dostępu przez przeglądarkę.

Problem jest rozwiązany tylko wtedy, gdy aplikacja loguje się, listuje pliki, wysyła, pobiera, wznawia i synchronizuje w zamierzonych warunkach na pierwszym planie i w tle. Jeśli dostęp przez web pozostaje jedyną działającą ścieżką, kontynuuj śledzenie punktu końcowego specyficznego dla mobilnych zamiast traktować serwer jako ogólnie zdrowy.