Какова должна быть полезная нагрузка разработчика в биллинге in-app in-app v3 api?

Я использую биллинг в приложении в своем приложении, чтобы разблокировать премиальные функции. Платеж в приложении настроен правильно. Все кажется прекрасным, кроме "полезной нагрузки разработчика".

Пример приложения говорит

 /*
     * TODO: verify that the developer payload of the purchase is correct. It will be
     * the same one that you sent when initiating the purchase.
     *
     * WARNING: Locally generating a random string when starting a purchase and
     * verifying it here might seem like a good approach, but this will fail in the
     * case where the user purchases an item on one device and then uses your app on
     * a different device, because on the other device you will not have access to the
     * random string you originally generated.
     *
     * So a good developer payload has these characteristics:
     *
     * 1. If two different users purchase an item, the payload is different between them,
     *    so that one user purchase can't be replayed to another user.
     *
     * 2. The payload must be such that you can verify it even when the app wasn't the
     *    one who initiated the purchase flow (so that items purchased by the user on
     *    one device work on other devices owned by the user).
     *
     * Using your own server to store and verify developer payloads across app
     * installations is recommended.
     */

Пример приложения использует пустую строку в качестве полезной нагрузки разработчика. Мой вопрос: какую строку использовать в качестве полезной нагрузки разработчика? Могу ли я использовать основной идентификатор электронной почты пользователя?

Ответ 1

Пожалуйста, проверьте ниже ответ, он может решить вашу проблему:

если вы используете расходуемый элемент (управляемый элемент), вы можете использовать произвольную сгенерированную строку

шаг 1: до создания метода create объявите это:

         private static final char[] symbols = new char[36];

                static {
                    for (int idx = 0; idx < 10; ++idx)
                        symbols[idx] = (char) ('0' + idx);
                    for (int idx = 10; idx < 36; ++idx)
                        symbols[idx] = (char) ('a' + idx - 10);
                }

Шаг 2: установите класс RandomString и SessionIdentifierGenerator в своей деятельности.

          public class RandomString {

        /*
         * static { for (int idx = 0; idx < 10; ++idx) symbols[idx] = (char)
         * ('0' + idx); for (int idx = 10; idx < 36; ++idx) symbols[idx] =
         * (char) ('a' + idx - 10); }
         */

        private final Random random = new Random();

        private final char[] buf;

        public RandomString(int length) {
            if (length < 1)
                throw new IllegalArgumentException("length < 1: " + length);
            buf = new char[length];
        }

        public String nextString() {
            for (int idx = 0; idx < buf.length; ++idx)
                buf[idx] = symbols[random.nextInt(symbols.length)];
            return new String(buf);
        }

    }

    public final class SessionIdentifierGenerator {

        private SecureRandom random = new SecureRandom();

        public String nextSessionId() {
            return new BigInteger(130, random).toString(32);
        }

    }

шаг 3: передать полезную нагрузку в ваш запрос puchase:

RandomString randomString = new RandomString(36);
            System.out.println("RandomString>>>>" + randomString.nextString());
            /* String payload = ""; */
            // bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ
            String payload = randomString.nextString();
            Log.e("Random generated Payload", ">>>>>" + payload);

        Log.d(TAG, "Launching purchase flow for infinite gas subscription.");
            mHelper.launchPurchaseFlow(this, SKU_GAS,
                    IabHelper.ITEM_TYPE_INAPP, RC_REQUEST,
                    mPurchaseFinishedListener, payload);

для дополнительной информации проверьте эту ссылку: Токен, который идентифицирует пользователя

Надеюсь, что это решит вашу проблему.

Ответ 2

Для меня случайная строка не полезна, поскольку, во-первых, она должна зависеть от пользователя, который ее купил, а не от устройства, которое было куплено. Во-вторых, это не потребляемый предмет, поэтому пустая строка может подойти, но не идеальна.

Таким образом, мой путь вокруг него заключается в создании зашифрованного хэша на основе ключа. Каждый раз, когда совершается покупка, он однозначно идентифицируется, поскольку хэш никогда не должен быть одинаковым (это зависит от метода хеширования, такого как bcrypt).

Так как ключ одинаковый на всех устройствах, он легко расшифровывает и проверяет правильность секретного сообщения.

Чтобы ключ оставался в секрете, я использовал различные функции манипуляции строками, чтобы замаскировать его, чтобы он не сохранялся видимым образом.

Пример анимации текста можно найти здесь: Android в биллинге приложений: обеспечение открытого ключа приложения

String Base64EncodedPublicKey key = DecrementEachletter("Bl4kgle") + GetMiddleBit() + ReverseString("D349824");

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