Dokumenty Portfela Google (w przypadku towarów cyfrowych) powiedz:
Uwaga: te procedury obsługi wywołań zwrotnych nie są bezpieczne. Ktoś mógłby skorzystać Firebug lub Chrome Developer Tools, aby wywołać jedną z funkcji, kpiąc z sukcesu lub porażki. Powinieneś potwierdzić zakup na serwer.
Link w cytacie służy do określenia zwrotnego adresu URL.
Ale skoro jwt jest podpisany przez Google - dlaczego jest to potrzebne? Możemy po prostu sprawdzić podpis handlowiec sukcesu„s jwt in the page” to codebehind na serwerze.
(A jeśli podpisywanie nie jest wystarczające - nie powinno też wystarczyć w adresie zwrotnym, ponieważ jeśli ktoś odkryje adres URL - może wysłać tam test POST i problem powróci.)
Odpowiedzi:
7 dla odpowiedzi № 1- Adres URL wywołania zwrotnego służy do informowania, że dokonano zakupu
- Weryfikujesz opublikowane dane przed ich faktycznym „zużyciem”, nie powinno to mieć znaczenia, czy Twój adres zwrotny zostanie „odkryty” na wolności.
- Mówisz Google, że możesz z powodzeniem zapisz wspomnianą kolejność w swoich systemach i tymoże „zrealizować” wspomniane zamówienie. W przeciwnym razie, jeśli z jakiegoś powodu twój koniec nie był w stanie nagrać / przetworzyć / itd. Zamówienia, co oznacza, że nie udało ci się go zrealizować, użytkownik (kupujący) również musi o tym wiedzieć.
Nie testowałem tego (używam adresu zwrotnego)
Dokumentacja stwierdza *GDYBY* określasz adres zwrotny . Możesz więc spróbować nie podać jednego z nich i przetworzyć sposób opisany powyżej (który jest nadal „po stronie serwera”).
Możliwy problem
Zakładając, że twój test działa, różnica między nimi:
w scenariuszu z adres zwrotny, wszystkie zainteresowane strony, kupujący,ty i Google jesteście „zsynchronizowani” - jeśli z jakiegoś powodu nie możecie się spełnić, macie problemy z serwerem po swojej stronie itp., wówczas transakcja nie powiedzie się (nie wygenerowano zamówienia) dla wszystko.
w scenariuszu bez adres zwrotny, zakładając sukces, transakcja może mają różne stany:
- Google: Dobra, zarejestrowana, na liście transakcji portfela kupującego
- Twoje systemy: być może dobre, czy nie, a nawet nie nagrane
- na podstawie danych przetwarzanych przez twoją stronę w tym czasie
- każdy błąd skryptu na kliencie / przeglądarce lub inny powód pochodzący od strony klienta, który może uniemożliwić przetwarzanie strony
- Użytkownik / kupujący - ma zamówienie w swoich transakcjach w Portfelu - „sukces”, jeśli chodzi o Google
Mam nadzieję że to pomoże...
Aktualizacja:
Jest jeszcze jedna „korzyść” (może mieć krytyczne znaczenieniektóre przepływy) w zakresie bezpieczeństwa. Dzięki adresowi zwrotnemu otrzymujesz szczegóły zamówienia na kolejny etap weryfikacji (np. Na podstawie identyfikatora zamówienia). Możesz sprawdzić, czy zamówienie wysłane przez / z klienta jest „ważne” (niezależnie od reguły biznesowej - np. if order-id exists then.....), ponieważ następuje wywołanie zwrotne sukcesu po zwrotny.
na przykład kpić, odtwarzając ponownie taki sam (ważny) JWT (w granicach iat / wszelkie daty ważności)
Mogą istnieć niezliczone przepływy, które wymyślają sprzedawcy / deweloperzy w swojej aplikacji, więc użycie „procesów weryfikacji adresu URL zwrotnego” zmniejsza potencjalne problemy.
Hth ....
0 dla odpowiedzi nr 2
Korzystam z usług zwrotnych do dostarczania towarów (w naszym przypadku biletów elektronicznych). Zaimplementowałem postback portfela, co daje mi różne parametry, takie jak identyfikator użytkownika google.
Nie widzę, jak mogę ustalić, kim jest użytkownik, więc bez tego nie mogę wysłać im cyfrowego dobra. Czy jest jakiś sposób, żeby to zdobyć?
W innych systemach podawałem identyfikator zamówienia, który pojawiał się w przycisku płatności i pojawiał się poprzez wywołanie zwrotne. Nie widzę takich danych wejściowych w przykładach kodów ani w tutorialach.
Thx Paul
Uwaga: później odgadłem odpowiedź, przetestowałem ją i podałem tutaj: jak uzyskać informacje o użytkowniku w portfelu Google
-1 dla odpowiedzi nr 3
Jak mówią dokumenty, cały kod po stronie klienta można łatwo zmienić za pomocą różnych narzędzi programistycznych przeglądarki i dlatego nie należy mu ufać.
Myślę, że chodzi im o to, żejavascript może być zmanipulowany, tak aby twój serwer myślał, że płatność została dokonana, a użytkownik otrzymuje produkt, za który tak naprawdę nie zapłacił.
Jeśli ktoś odkryje adres URL i zamieszcza na nim posty, nie ma kontroli nad kodem serwera, więc serwer pobierze płatność z karty, więc to naprawdę nie jest problem.