Понимание платежей в Facebook Выполнение потока

Question

Я учусь, как реализовать Поток выполнения Facebook .Я не могу понять смысл использования request_id (шаги 1 и 2).Идея состоит в том, что мой сервер генерирует request_id, а затем, когда приложение получает закодированный ответ от Facebook, сравните детали в этом ответе с сохраненными данными на моем сервере (используя request_id в качестве ключа).

Какова цель этой проверки?

В ней говорится:

Самый безопасный способ проверки заказа - использовать параметр signature_request из обратного вызова JavaScript, так как это было закодировано с использованием секрета приложения и не может быть изменено клиентом.

Итак, если мы доверяем этим данным и ими нельзя манипулировать ,зачем нам для дополнительной проверки?Если, с другой стороны, им можно манипулировать, то как эта мера не позволяет просто передать тот же запрос моему серверу и использовать возвращенный request_id как часть создания манипулируемого signed_request.

Answer 1

Давайте разберемся с этим и попытаемся понять, как использовать sign_request.

Там сказано: Самый безопасный способ проверки заказа - использовать параметр Sign_request из обратного вызова JavaScript, поскольку он был закодирован с использованием секрета приложения и не может быть изменен клиентом.

signature_request кодируется серверами Facebook с использованием секрета приложения это знает только Facebook и разработчик приложений. Ни один другой клиент не будет возможность генерировать подписанный запрос без секретного ключа. Следовательно, это самый безопасный способ подтверждения заказа.

Как клиент может манипулировать подписанным запросом?

Если ваш сайт уязвим для XSS, злоумышленник может внедрить код JavaScript в ваше приложение.

Как сервер приложений узнает, что подписанный запрос не сгенерирован Facebook?

Когда сервер приложений получает signature_request, он должен проверить подпись singed_request. Проверка подписи будет успешной, только если она была сгенерирована Facebook, потому что только Facebook имеет ваш секретный ключ.

Метод проверки подлинности цифровых данных известен как Цифровая подпись .

Answer 2

Есть причины буксировки использования request_id

Эта информация затем может быть использована позже в потоке платежей, чтобы убедиться, что покупка не осуществлялась междуклиент и сервер, или для получения платежа посредством вызова API Graph в тех случаях, когда идентификатор платежа неизвестен.

1. Хотя данными нельзя манипулировать, это обеспечивает дополнительнуюsecurity.
2. Позволяет получить платеж без использования идентификатора платежа.

Примечание: request_id не является обязательным, и вы, безусловно, можете достичь цели, используя альтернативные способы.

Сервер разработчика проверяет платеж, расшифровывая подписанный запрос от Клиента и используя полезную нагрузку проверки платежа одним из следующих двух способов:

1. Использование параметра request_id для сравнениядетали покупки против сохраненных данных от шага 1.
2. Выполнение вызова API Facebook Graph для подтверждения того, что данные платежа соответствуют ожидаемым

С помощью signed_request существует 2 способа:подтвердить платеж.

1. Если вы сгенерируете request_id, вы можете выполнить проверку, не обращаясь к серверу FB без дальнейших запросов, поскольку request_id зарезервировано в вашей базе данных.Так что одним из преимуществ использования request_id является то, что вы можете избежать дополнительного запроса, например, позвонив по номеру Graph API.

2. Если у вас нет request_id, вы должны использоватьPayment ID и снова отправьте запрос в FB.

Подробнее о проверке через Graph API .