Odrzucenie sklepu z aplikacjami IPv6

Nasza aktualizacja została dzisiaj dwukrotnie odrzucona z powodu problemów z łącznością sieciową ipv6. Nasz kod sieciowy nie zmienił się między poprzednią a obecną wersją.

Aplikacja wysyła tylko żądania sieciowe HTTPS do api.metooapp.io, które jest poprawnie skonfigurowane dla IPv6 [ 0 ] i działa za routingiem53 w AWS. W kodzie nie ma zakodowanych adresów IP.

Nie mogę odtworzyć tego problemu, nawet po wykonaniu czynności związanych z utworzeniem sieci IPv6 pod adresem [ 1 ], do której należy łącze podane w powiadomieniu o odrzuceniu. Wygląda na to, że nie tylko ja mam ten problem [ 2 ].

Po pewnym stresie mogę potwierdzić, że problem polegał na tym, że nasz backend nie był poprawnie skonfigurowany pod kątem IPv6. Najwyraźniej AWS nie obsługuje IPv6 ani DNS tylko dla IPv6 za pośrednictwem Route53. Skończyło się na tym, że na razie przeniosłem cały internet naprzeciwko części zaplecza od AWS.

Chciałem to zostawić, ponieważ myślę, że prawdopodobnie pojawią się inne osoby, które będą miały podobne problemy, gdy ludzie zaczną przesyłać aktualizacje po przekroczeniu ograniczenia dotyczącego tylko IPv6. Najlepsze narzędzie do testowania gotowości serwera / dns to: http://ready.chair6.net/

Należy pamiętać, że Wsparcie IPv6 tylko sieci i IPv6 i App review link może być bardzo pomocne w ustalaniu, co jest problem z odrzucenia jabłek. W tym konkretnym przypadku artykuły jasno stwierdzają, że można skonfigurować sieć testową DNS64 / NAT64, ale „Ta sieć testowa nie jest dokładnie taka sama jak sieć używana przez App Review”, dlatego wszystko może działać w środowisku testowym i nadal mieć aplikacja została odrzucona.

Ponadto:

Sieć App Review, podobnie jak sieci wdrażane przez dostawców usług, obsługuje łączność IPv6-IPv6. Tak więc, jeśli twój serwer obsługuje IPv6, twoja aplikacja będzie komunikować się z nim bezpośrednio, bez przechodzenia przez translator NAT64. Jest to ogólnie rzecz biorąc dobra rzecz, ale może się zepsuć, jeśli twój serwer twierdzi, że obsługuje IPv6, ale obsługa IPv6 jest zepsuta. Na przykład, jeśli: nazwa DNS jest nieprawidłowa, DNS jest poprawny, ale serwer nie nasłuchuje na IPv6, serwer nasłuchuje na IPv6, ale kończy się niepowodzeniem, gdy przychodzi żądanie przez IPv6

Więc jeśli twój serwer backendu obsługuje IPv6, sieć testowa Apple będzie go używać i tak właśnie było w tym przypadku.

Dodaję to jako punkt odniesienia i punkt wyjścia dla innych użytkowników, którzy mają ten sam problem

Napotkaliśmy ten sam problem i okazało się, że podczas konfigurowania rekordu AAAA dla IPv6, ponieważ tak naprawdę nie mieliśmy obsługi IPv6 (używamy również Route53), wszystko zepsuło. Usunięcie rekordu AAAA rozwiązało problem.

Złożyłem radar dotyczący rozbieżności między dokumentacją do testowania a konfiguracją, z której korzysta przegląd aplikacji - byliśmy w stanie ją zdiagnozować tylko dlatego, że nasz CTO był w WWDC i był w stanie połączyć się z ich siecią, co nie jest dokładnie sytuacją możemy regularnie rozmnażać.

Znaleźliśmy się w podobnej sytuacji. Nasza aplikacja została odrzucona z powodu problemów z łącznością w sieciach IPv6. Również nasze serwery używają AWS.

Wykonałem Test IPv6 DNS64 / NAT64 bez żadnego problemu z mojej strony i postanawiamy złożyć odwołanie od tego odrzucenia.

Wyjaśniliśmy, że test po naszej stronie zakończył się sukcesem i korzystamy z infrastruktury AWS.

Po kolejnych dwóch dniach aplikacja została ponownie sprawdzona i zaakceptowana

napotkaliśmy ten sam problem。 Nasza aplikacja została odrzucona przez okres serwowania z powodu IPv6. Ale zostaliśmy przetestowani w sieci ipv6 skonfigurowanej jako oficjalny dokument APPLE: https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition_html uid / TP40010220-CH213-SW1

Nasza aplikacja jest odrzucana za pierwszym razem, konfigurujemy lokalne środowisko testowe na podstawie dokumentu Apple i stwierdzamy, że nasza biblioteka curl jest zbyt stara bez domyślnie włączonego ipv6. Dlatego tworzymy najnowszą bibliotekę curl i działa. Ale znowu jest odrzucony z tego samego powodu. Sprawdzam wiele informacji, stwierdzam, że ktoś miał takie same doświadczenia, wystarczy złożyć skargę do recenzenta Apple, aby powiedzieć, że Twoja aplikacja działa dobrze w środowisku testowym i poprosić o pomoc inżyniera, jeśli nalegają, że wystąpił jakiś błąd. Zespół Apple zatwierdził naszą aplikację w weekend, kiedy zobaczył nasze skargi.

Jak wiem, są 2 problemy, które musisz sprawdzić. Czy zakodujesz na stałe adres IP w swojej aplikacji? Czy konfigurujesz rekord AAAA dla domeny serwera, aby pokazać, że obsługuje IPv6, ale serwer nie nasłuchuje IPv6. Jeśli tak, po prostu usuń ten rekord AAAA w ustawieniach domeny z witryny dostawcy domeny.

Biblioteka osiągalności musi obsługiwać ustawienia sieciowe IPv6. Więc użyj tej klasy osiągalności.

https://developer.apple.com/library/content/samplecode/Reachability/Introduction/Intro.html#//apple_ref/doc/uid/DTS40007324

To drugi raz, kiedy napotkałem ten problem po 6 miesiącach. Wcześniej było to w projekcie Objective-C przy użyciu AFNetworking i korzystałem z tego rozwiązania i działało za jednym zamachem. Teraz to samo stało się z Alamofire. Chłopaki, to rozwiązanie działało u mnie 2 razy i stwierdziłem, że to pytanie pojawia się jako pierwsze w Google, więc publikuję odpowiedź.

Wyszukaj w obszarze roboczym hasło AF_INET i zmień je na AF_INET6 w dowolnym miejscu. Myślę, że musi znajdować się w bibliotece AFNetworking lub bibliotece Alamofire, jeśli jej używasz. Znajduje się w klasie NetworkReachabilityManager.

Znalazłem tę odpowiedź z poniższego źródła.

https://stackoverflow.com/a/38196337/4030971

EDYCJA: - 24 czerwca -

Pomogło mi to wiele razy, ale jest też dziwne rozwiązanie tego problemu. W naszym ostatnim projekcie zastosowaliśmy to rozwiązanie, ale Apple nadal odrzuciło wniosek. Następnie nakręciliśmy film, który pokazywał, że aplikacja działa poprawnie z połączeniem z siecią NAT64 utworzoną na komputerze Mac z opcją udostępniania Wi-Fi. Zwróciliśmy się o sprawdzenie wraz z filmem, a oni zatwierdzili wniosek. Więc jeśli skończyłeś ze wszystkimi opcjami, wypróbuj również tę.

Możesz sprawdzić swoje API na poniższej stronie internetowej, czy twoje API iPV6 jest skonfigurowane, czy nie!

http://ipv6-test.com/validate.php

Przeprowadziłem Test IPv6 DNS64/NAT64bez żadnego problemu zgodnie z dokumentacją Apple

jednak nie jesteśmy w stanie odtworzyć problemu (awaria). Pomyślnie zainstalowaliśmy aplikację na naszych urządzeniach bez awarii.

• Nagraliśmy film przedstawiający cały proces testowania (obejmujący pokazanie łączności, pobieranie z lotu testowego, połączenie sieciowe NAT64, działanie aplikacji)
• i apeluj o odrzucenie wraz z plikiem wideo

Wreszcie sklep z aplikacjami ZATWIERDZIŁ moją aplikację

Napotkałem to samo odrzucenie aplikacji podczas korzystania z zestawu SDK Facebooka. Jeśli używasz Facebook SDK do logowania, niezwykle ważne jest wylogowanie użytkownika po zakończeniu sesji. W przeciwnym razie w przyszłości wystąpią podobne odrzucenia aplikacji. Poniżej zamieściłem kod, aby pomóc tym, którzy mogą mieć podobne problemy.

let loginManager = FBSDKLoginManager()
loginManager.logOut()

Rozwiązałem problem, wysyłając im wideo pokazujące, że moja aplikacja działa na ipv6.

1. Skonfiguruj IPv6 z systemem macOS
2. Taśma wideo, że masz połączenie z udostępnioną siecią IPv6 i udowodnij, że Twoja aplikacja działa w tym środowisku.

moja aplikacja jest odrzucana dwa razy w sklepie z aplikacjami. Dają błąd przy logowaniu do Twittera na iPhonie z systemem operacyjnym 11.4. Główny problem, który mamy z powodu adresu zwrotnego Twittera, który nie jest ustawiony na koncie programisty Twittera. kiedy ustawię URL wywołania zwrotnego na koncie programisty Twittera. To rozwiązuje mój problem. Kiedy nie ustawiamy adresu URL wywołania zwrotnego na koncie programisty na Twitterze, logowanie do Twittera jest pomyślne, gdy urządzenie ma aplikację Twitter. ale w przypadku braku aplikacji twitter na urządzeniu daje zabroniony błąd 403.

Tak więc ustawienie adresu URL wywołania zwrotnego rozwiązuje mój problem i aplikacja jest akceptowana.

Dziękuję Ci