Jaki powinien być ładunek programisty w aplecie v3 aplikacji rozliczeniowej w aplikacji na Androida?

Question

W mojej aplikacji wdrażam rozliczenia w aplikacji, by odblokować funkcje premium. Rachunki w aplikacji konfiguruje się prawidłowo. Wszystko wydaje się w porządku, z wyjątkiem tego, co robią deweloperzy.

Aplikacja próbka mówi

/* 
    * 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's 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. 
    */ 

Aplikacja próbki wykorzystuje pusty ciąg jako deweloper ładowności. Moje pytanie brzmi, jaki ciąg znaków należy użyć jako ładunek programisty? Czy mogę użyć podstawowego identyfikatora e-mail użytkownika?

Answer 1

Proszę sprawdzić poniżej odpowiedź, może rozwiązać swój problem:

jeśli używasz przedmiot konsumpcji (zarządzanego elementu), a następnie można użyć losowo generowane ciąg

krok 1: zanim na stworzenie metody declare to:

  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); 
       } 

krok 2: set RandomString i SessionIdentifierGenerator klasa w swojej działalności

  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); 
     } 

    } 

krok 3: pass ładowność do żądania 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); 

dłużej inforamation sprawdzić ten link: Token that identify the user

nadzieję, że to rozwiąże problem.

Answer 2

Dla mnie losowy ciąg znaków nie jest przydatny, ponieważ po pierwsze, musi być zależny od użytkownika, który go kupił, a nie od urządzenia, na którym został kupiony. Po drugie, jest to przedmiot, który nie nadaje się do konsumpcji, więc pusty ciąg może pasować, ale nie jest idealny.

Moim sposobem jest stworzenie zaszyfrowanego skrótu na podstawie klucza. Za każdym razem, gdy dokonywany jest zakup, można go jednoznacznie zidentyfikować, ponieważ wartość mieszania nigdy nie powinna być taka sama (zależy to od metody mieszania, takiej jak bcrypt).

Ponieważ klucz jest taki sam we wszystkich urządzeniach, można go odszyfrować i sprawdzić, czy tajna wiadomość jest prawidłowa.

Aby klucz pozostał tajny, użyłem różnych funkcji manipulowania ciągami, aby go zamaskować, aby nie był przechowywany w widoczny sposób.

Przykładem maniluation tekstu można znaleźć tutaj: Android In App Billing: securing application public key

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

Ta metoda tworzenia skrótu na podstawie indeksu pozwala ładunek być unikalne i rozpoznawalne, a jednocześnie jako dość bezpieczny. Nie jest kuloodporny, ale z pewnością sprawia, że ​​trudno go złamać.