Quale dovrebbe essere il payload dello sviluppatore in Android app-fatturazione v3 api?

Question

Sto implementando la fatturazione in-app nella mia app per sbloccare funzionalità premium. La fatturazione in-app viene impostata correttamente. Tutto sembra a posto, a parte la cosa del "payload degli sviluppatori".

L'applicazione di esempio dice

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

L'applicazione di esempio utilizza una stringa vuota come payload sviluppatore. La mia domanda è quale stringa usare come payload degli sviluppatori? Posso utilizzare l'ID e-mail principale dell'utente?

Answer 1

Si prega di verificare di seguito la risposta, si può risolvere il problema:

se si utilizza materiale di consumo (voce gestito) quindi è possibile utilizzare stringa casuale generato

passo 1: prima su creare metodo di dichiarare questo:

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

fase 2: impostare RandomString e SessionIdentifierGenerator classe nella vostra attività

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

    } 

Fase 3: passaggio payload nella richiesta 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); 

per più inforamation controllare questo link: Token that identify the user

auguriamo che possa risolvere il problema.

Answer 2

Per me una stringa casuale non è utile in primo luogo, deve dipendere dall'utente che l'ha acquistata, non dal dispositivo su cui è stata acquistata. In secondo luogo, è un articolo non consumabile, quindi una stringa vuota può adattarsi, ma non è l'ideale.

Quindi la soluzione è creare un hash crittografato basato su una chiave. Ogni volta che viene effettuato un acquisto, è identificabile in modo univoco in quanto l'hash non dovrebbe mai essere lo stesso (ciò dipende dal metodo di hashing, come bcrypt).

Poiché la chiave è la stessa su tutti i dispositivi, è facile decrittografare e verificare che il messaggio segreto sia corretto.

Affinché la chiave rimanga un segreto, ho utilizzato varie funzioni di manipolazione delle stringhe per mascherarlo in modo che non vengano memorizzate in modo visibile.

Un esempio del maniluation testo può essere trovato qui: Android In App Billing: securing application public key

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

Questo metodo di creazione di un hash basato su una chiave permette il carico utile per essere unico e riconoscibile, al tempo stesso come essere ragionevolmente sicuro. Non è a prova di proiettile, ma sicuramente lo rende difficile da decifrare.