#java #android #servlets #in-app-billing
#java #Android #сервлеты #in-app-billing
Вопрос:
При реализации биллинга в приложении для приложения Android я столкнулся с проблемой.
Позвольте мне сначала объяснить сценарий
, у нас есть сервер контента (сервер данных), на котором есть список продуктов.
Когда пользователь выбирает один из списка, он может его приобрести.
Логика покупки выполняется отлично после того, как я ввел данные своей кредитной карты, используя свою тестовую учетную запись.
В ответ я получаю подписанные данные на устройстве Android.
Мой вопрос
1. Должен ли я проверять подписанные данные на устройстве Android, а затем отправлять некоторую информацию или данные на сервер контента, который в свою очередь отправляет продукт (я думаю, это может быть нехорошо, поскольку на стороне сервера нет потока для проверки того, действителен запрос или нет, или точнее; что запрос действителен или нет)?данные подписи генерируются Google Market или нет)?
2. Если мне нужно проверить данные на стороне сервера, как я могу это сделать? Должен ли я отправлять их в Google Market (если да, то с помощью какого веб-сервиса или API)?
Пожалуйста, помогите мне исправить это.
Заранее спасибо.
Ответ №1:
Для вашего второго вопроса, хэшируйте (например: MD5, SHA) данные и отправьте хэш вместе с данными на сервер. На сервере создайте хэш данных и сравните хэши, чтобы проверить их.
Комментарии:
1. Как я могу создать хэши и сравнить их на стороне сервера? пожалуйста, изучите это подробнее.
2. Алгоритмы хэширования @Naved являются детерминированными. Если вы используете один и тот же алгоритм хеширования для одного и того же содержимого, вы должны получить тот же результат, независимо от компьютера, на котором находятся данные.
3. Можете ли вы привести какой-либо пример руководства или поделиться примером программы? Мне очень жаль, я не смог полностью понять это.
4. @yogiam, спасибо за подсказку. Моя команда настроила сервер, который генерирует хэш-строку и отправляет ее на устройство. Эта строка вместе с одноразовым номером (который также генерируется на стороне сервера) используется для запуска транзакции на стороне устройства. Затем устройство отправляет этот хэш вместе с подписанными данными на сервер, а затем сервер проверяет запрос. Это работает нормально, но мне нужно еще немного времени, чтобы протестировать его дальше. Спасибо за вашу поддержку.
Ответ №2:
Чтобы ответить на ваши вопросы, вам нужно сначала создать продукт в приложении, используя какой-то идентификатор, который я затем привяжу к базе данных, которая у вас есть на вашем сервере. Затем с помощью веб-сервисов вы запрашиваете свою базу данных и смотрите, совпадает ли идентификатор в приложении с идентификатором в вашей базе данных продуктов. Кроме того, вы можете использовать одноразовые номера безопасности и подписи для проверки. В основном вы позволяете Google обрабатывать продукты, и поэтому вам нужно будет моделировать продукты в приложении после вашей БД. Если у вас слишком много продуктов, вам придется обращаться с этим стандартным способом создания мобильного веб-сайта….
РЕДАКТИРОВАТЬ: Ну, когда вы делаете запрос, то есть покупаете, вы сначала выполняете REQUEST_PURCHASE, затем запускаете PendingIntent, который возвращается рынком. Затем вы обрабатываете намерения рассылки, отправляемые Market. Вы указываете четыре ключа в запросе, а затем отправляете запрос на покупку:
Bundle request = makeRequestBundle("REQUEST_PURCHASE");
request.putString(ITEM_ID, mProductId);
// Note that the developer payload is optional.
if (mDeveloperPayload != null) {
request.putString(DEVELOPER_PAYLOAD, mDeveloperPayload);
Bundle response = mService.sendBillingRequest(request);
// Do something with this response.
}
Затем вам нужно использовать PendingIntent для запуска checkoutUI (будьте осторожны с различиями от 1.6 до 2.0, где 1.6 требует, чтобы это запускалось отдельно от действия). взгляните на PurchaseObserver.java в примерах Google.
«Приложение Android Market отправляет широковещательное намерение RESPONSE_CODE, которое предоставляет информацию об ошибке запроса. Если запрос не генерирует ошибку, широковещательное намерение RESPONSE_CODE возвращает RESULT_OK, что указывает на то, что запрос был успешно отправлен. (Чтобы было ясно, ответ RESULT_OK не указывает на то, что запрошенная покупка была успешной; это указывает на то, что запрос был успешно отправлен на Android Market.) «
Комментарии:
1. Это то, что мы сейчас делаем. Но мой вопрос в том, когда мы получили одноразовые номера и подпись с Market, должен ли я отправлять их на сервер контента? Если да, то как сервер контента узнает, что подпись и одноразовые номера были получены не вручную, а сгенерированы транзакцией Google Market?
2. Спасибо, что потратили время на написание этого ответа. Однако я думаю, что мой вопрос может не соответствовать его требованию. Хорошо, позвольте мне объяснить. Я обрабатываю все вещи на стороне устройства. После того, как я получил подписанные данные, я должен отправить их на сервер контента. Мой вопрос заключается в том, как сервер контента проверяет, что подписанные данные, отправленные устройством, на самом деле являются транзакцией, а не поддельной.
3. У вас должен быть какой-то способ проверки, отправив сертификат / ключ, а затем программа отправляет обратно ключ ответа. Это действительно единственный способ убедиться, что это не поддельный запрос.
4. Вы имеете в виду, что вы одобряете то, что говорит Йогиам?