IN_APP_VALIDATION to LinkedIn, który prosi właściciela konta o zatwierdzenie logowania z wnętrza aplikacji LinkedIn. Nie ma kodu do wpisania i w tym tkwi cała trudność: potwierdzenie dzieje się na telefonie, a nie w twoim żądaniu, więc nic z tego nie dociera do kodu, który logowanie rozpoczął.
Dlaczego naiwna implementacja wisi w nieskończoność
Oczywisty projekt to czekać, aż wywołanie połączenia coś zwróci. Nigdy nie zwraca niczego użytecznego: zwraca checkpoint, natychmiast, a potwierdzenie przychodzi kilka minut później. Drugi oczywisty projekt to odpytywać wiersz konta w pętli. To bliżej, ale wiersz nie nadąża za potwierdzeniem — może jeszcze długo pokazywać CHECKPOINT po tym, jak konto jest już całkowicie sprawne.
Rozstrzyga poproszenie konta, żeby zrobiło coś, co potrafi tylko żywe konto. MakeHybrid prosi konto o pobranie własnego profilu; jeśli to działa, konto jest połączone, cokolwiek mówi wiersz.
Część wbrew intuicji
Po potwierdzeniu odpowiedź na checkpoint często wraca jako porażka — tamtej weryfikacji już nie ma, bo potwierdzenie ją zużyło. Tak właśnie wygląda sukces widziany z zewnątrz, i dlatego każda porażka trasy checkpoint musi sprawdzić, czy konto ożyło, zanim nazwie siebie porażką.
O co ludzie pytają
Czy agent SI w pokoju projektowym może zatwierdzić potwierdzenie w aplikacji?
Nie. Potwierdzenie dzieje się w aplikacji LinkedIn na telefonie właściciela, do którego żaden agent SI nie ma dostępu. Agent może za to sensownie powiedzieć, że czeka, i sprawdzić konto po potwierdzeniu, prosząc je o coś, co potrafi tylko żywe konto.
Czy agent SI ma ponawiać, aż zadziała?
Nie. Ponowienie zaczyna nowe logowanie i nowy monit na telefonie, a pierwsze potwierdzenie nie zatwierdza wtedy niczego. Jedno sprawdzenie po potwierdzeniu wystarczy.