React-native-iap: IOS जाँचता है कि क्या स्वतः नवीनीकरण सदस्यता अभी भी सक्रिय है

को निर्मित 27 सित॰ 2018 · 61टिप्पणियाँ · स्रोत: dooboolab/react-native-iap

प्रतिक्रिया देशी-आईएपी . का संस्करण

2.2.2

जिन प्लेटफार्मों में आपको त्रुटि का सामना करना पड़ा (आईओएस या एंड्रॉइड या दोनों?)

आईओएस

अपेक्षित् व्यवहार

आरएनआईएपी एपीआई का उपयोग करके हम जांच सकते हैं कि ऑटो-नवीनीकरण सदस्यता अभी भी सक्रिय है या नहीं

वास्तविक व्यवहार

एंड्रॉइड पर यह जांचने के लिए यह कर रहा हूं:

export const isUserSubscriptionActive = async (subscriptionId) =>{
    // Get all the items that the user has
    const availablePurchases = await getAvailablePurchases();
    if(availablePurchases !== null && availablePurchases.length > 0){
        const subscription = availablePurchases.find((element)=>{
            return subscriptionId === element.productId;
        });
        if(subscription){
             // check for the autoRenewingAndroid flag. If it is false the sub period is over
              return subscription["autoRenewingAndroid"] == true;
            }
        }else{
            return false;
        }
    }
}

ios पर इसे जांचने के लिए कोई ध्वज नहीं है, और getAvailablePurchases विधि की गई सभी खरीदारियों को वापस कर देती है, यहां तक कि वे सब्सक्रिप्शन भी जो इस समय सक्रिय नहीं हैं।

क्या इसे जांचने का कोई तरीका है?

सादर,
मार्कोस

📱 iOS 🚶🏻 stale

स्रोत

marcosmartinez7

👍4

सबसे उपयोगी टिप्पणी

यहां वह फ़ंक्शन है जिसका मैं उपयोग कर रहा हूं जो एंड्रॉइड और आईओएस दोनों पर काम करता है, आईओएस पर ठीक से सॉर्ट करना सुनिश्चित करने के लिए हमें नवीनतम रसीद डेटा मिलता है:

import * as RNIap from 'react-native-iap';
import {ITUNES_CONNECT_SHARED_SECRET} from 'react-native-dotenv';

const SUBSCRIPTIONS = {
  // This is an example, we actually have this forked by iOS / Android environments
  ALL: ['monthlySubscriptionId', 'yearlySubscriptionId'],
}

async function isSubscriptionActive() {
  if (Platform.OS === 'ios') {
    const availablePurchases = await RNIap.getAvailablePurchases();
    const sortedAvailablePurchases = availablePurchases.sort(
      (a, b) => b.transactionDate - a.transactionDate
    );
    const latestAvailableReceipt = sortedAvailablePurchases[0].transactionReceipt;

    const isTestEnvironment = __DEV__;
    const decodedReceipt = await RNIap.validateReceiptIos(
      {
        'receipt-data': latestAvailableReceipt,
        password: ITUNES_CONNECT_SHARED_SECRET,
      },
      isTestEnvironment
    );
    const {latest_receipt_info: latestReceiptInfo} = decodedReceipt;
    const isSubValid = !!latestReceiptInfo.find(receipt => {
      const expirationInMilliseconds = Number(receipt.expires_date_ms);
      const nowInMilliseconds = Date.now();
      return expirationInMilliseconds > nowInMilliseconds;
    });
    return isSubValid;
  }

  if (Platform.OS === 'android') {
    // When an active subscription expires, it does not show up in
    // available purchases anymore, therefore we can use the length
    // of the availablePurchases array to determine whether or not
    // they have an active subscription.
    const availablePurchases = await RNIap.getAvailablePurchases();

    for (let i = 0; i < availablePurchases.length; i++) {
      if (SUBSCRIPTIONS.ALL.includes(availablePurchases[i].productId)) {
        return true;
      }
    }
    return false;
  }
}

andrewzey 27 अक्तू॰ 2018

👍30 🎉7 ❤3 👀2 🚀2

सभी 61 टिप्पणियाँ

मैं इसका भी पता लगाने पर काम कर रहा हूं। मैंने अभी तक इसका परीक्षण नहीं किया है, लेकिन जो मैं पढ़ रहा हूं उससे मैं यह इकट्ठा कर रहा हूं कि आईट्यून्स कनेक्ट में "साझा रहस्य" बनाकर और इसे 'पासवर्ड' कुंजी के साथ रिसीप्टियो को मान्य करने के लिए पास करना संभव है। मेरा मानना है कि इसके बाद यह एक JSON ऑब्जेक्ट लौटाएगा जिसमें एक कोड होगा जो सब्सक्रिप्शन की सत्यापन स्थिति और कुंजी नवीनतम_रसीद, नवीनतम_रसीद_इन्फो, और नवीनतम_एक्सपायर्ड_रसीद जानकारी को इंगित करेगा, जिसका उपयोग आप सदस्यता की स्थिति निर्धारित करने के लिए कर सकते हैं। मैं सचमुच इसका पता लगा रहा हूं इसलिए मुझे अभी इसका परीक्षण करना है। यह वही है जो मैं मुद्दों और ऐप्पल के दस्तावेज़ों से एक साथ रख रहा हूं। यदि यह काम करता है, तो इसे वास्तव में मुद्दों में दफन होने के बजाय दस्तावेज़ीकरण में बहुत स्पष्ट किया जाना चाहिए।
मेरा मानना है कि निम्नलिखित लिंक प्रासंगिक हैं:
https://developer.apple.com/library/archive/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateRemotely.html

203 #237

संपादित करें : मैं पुष्टि कर सकता हूं कि ऊपर वर्णित प्रक्रिया काम करती है। मुझे लगता है कि हमें डॉक्स में इसकी पूरी व्याख्या प्राप्त करने के लिए काम करना चाहिए। सदस्यता समाप्त हो गई है या नहीं यह निर्धारित करने के लिए मैं ऐप लॉन्च पर ऐसा कुछ लागू करूंगा:

RNIap.getPurchaseHistory()
        .then(purchases => {
                RNIap.validateReceiptIos({
                   //Get receipt for the latest purchase
                    'receipt-data': purchases[purchases.length - 1].transactionReceipt,
                    'password': 'whateveryourpasswordis'
                }, __DEV__)
                    .then(receipt => {
                       //latest_receipt_info returns an array of objects each representing a renewal of the most 
                       //recently purchased item. Kinda confusing terminology
                        const renewalHistory = receipt.latest_receipt_info
                       //This returns the expiration date of the latest renewal of the latest purchase
                        const expiration = renewalHistory[renewalHistory.length - 1].expires_date_ms
                       //Boolean for whether it has expired. Can use in your app to enable/disable subscription
                        console.log(expiration > Date.now())
                    })
                    .catch(error => console.log(`Error`))
        })

kevinEsherick 27 सित॰ 2018

👍17 🎉11 ❤8 😄6

@केविनएशेरिक

प्रतिभाशाली!

बस कुछ चीजें जो आपके कोड के बारे में इतनी तुच्छ नहीं हैं;

यह होना चाहिए

कॉन्स्ट समाप्ति = नवीनीकरण इतिहास [नवीकरण इतिहास। लंबाई - 1]। समाप्ति_डेट_एमएस

इसके बजाय (शायद सिर्फ एक टाइपो)

कास्ट समाप्ति =

2) उन लोगों के लिए जो नहीं जानते कि 'पासवर्ड' क्या है: 'जो भी आपका पासवर्ड है':

आप अपने इन ऐप पैमेंट के लिए अपनी साझा गुप्त कुंजी बना सकते हैं और इसे अपने ऐप पर उपयोग कर सकते हैं

चरण यहाँ हैं: https://www.appypie.com/faqs/how-can-i-get-shared-secret-key-for-in-app-purchase

+1 दस्तावेज़ों को अपडेट करने के लिए, शायद @dooboolab आप आईओएस और एंड्रॉइड में उपयोग के मामलों को अलग कर सकते हैं ऐसा लगता है कि कुछ चीजें अलग हैं। आप चाहें तो मैं आपकी मदद कर सकता हूं।

सादर

marcosmartinez7 9 अक्तू॰ 2018

👍3

@केविनएशेरिक

स्वतः नवीनीकरण सदस्यताओं के साथ क्या होता है?

ऐसा लगता है कि एक्सपायरी_डेट_एमएस पहली समाप्ति तिथि है, इसे अपडेट नहीं किया गया है

मैंने इसका परीक्षण किया है:

एक सदस्यता आइटम की सदस्यता लें
समाप्ति तिथि जांचें (जैसे 5 मिनट बाद)
10 मिनट इंतजार
सदस्यता अभी भी सक्रिय लगती है स्वतः नवीनीकरण सदस्यता है
अगर मैं जांचता हूं कि अंतिम नवीनीकरण रसीद की समाप्ति अभी भी बिंदु 2 के समान है

कोई विचार?

मेरा बुरा, समाप्ति तिथि अपडेट की गई प्रतीत होती है, इसमें कुछ समय लगता है।

मैं इस टिप्पणी को यहां छोड़ दूंगा यदि कोई भी इसी परिदृश्य में है।

सादर

marcosmartinez7 9 अक्तू॰ 2018

😄2

यह होना चाहिए
कॉन्स्ट समाप्ति = नवीनीकरण इतिहास [नवीकरण इतिहास। लंबाई - 1]। समाप्ति_डेट_एमएस
इसके बजाय (शायद सिर्फ एक टाइपो)
कास्ट समाप्ति =

ओह हाँ आप सही हैं, वह एक टाइपो था। मैंने इसका अर्थ और अधिक स्पष्ट करने के लिए नाम बदल दिया था लेकिन सभी घटनाओं को बदलना भूल गया था। मैंने इसे संपादित किया है, धन्यवाद।

और मेरे पास समाप्ति तिथि के साथ वह सटीक परिदृश्य नहीं था, लेकिन इसके साथ कुछ सामान था जो बिल्कुल भी स्वत: नवीनीकरण नहीं कर रहा था, हालांकि यह किसी भी तरह से अपने आप हल हो गया (जो मुझे चिंतित करता है, लेकिन मैं इतनी आईडी को पुन: उत्पन्न नहीं कर सकता कि और क्या करना है)। आपके पास जो मुद्दा था वह काफी सामान्य है। ऐप्पल के अंत में यह अपेक्षित व्यवहार है, इसलिए आपको सदस्यता समाप्त करने से पहले सदस्यता को नवीनीकृत करने के लिए एक बफर अवधि छोड़नी चाहिए। SO पर यह समस्या अधिक विस्तार से बताती है: https://stackoverflow.com/questions/42158460/autorenewable-subscription-iap-renewing-after-expiry-date-in-sandbox

kevinEsherick 10 अक्तू॰ 2018

धन्यवाद! बढ़िया जानकारी, कारण हो सकता है

इस मुद्दे के बारे में, मुझे लगता है कि @kevinEsherick कोड दस्तावेज़ों पर होना चाहिए यह

marcosmartinez7 10 अक्तू॰ 2018

👍1

हां। यदि आप में से कोई PR अनुरोध करता है तो मैं readme में एक साफ-सुथरे डॉक्टर की सराहना करूंगा। धन्यवाद।

hyochan 10 अक्तू॰ 2018

👍1

हाय दोस्तों। मैंने रीडमी में प्रश्नोत्तर अनुभाग जोड़ा है। आशा है कि आप में से कोई भी हमें इस मुद्दे के लिए PR दे सकता है।

hyochan 10 अक्तू॰ 2018

🎉1

मैं अगले कुछ दिनों में पीआर बनाने पर ध्यान दूंगा :)

kevinEsherick 11 अक्तू॰ 2018

मैं विशेष रूप से सदस्यता के लिए इस पुस्तकालय का उपयोग करना चाहता हूं। आईओएस और एंड्रॉइड दोनों। यह निर्धारित करने के लिए उचित तरीके का दस्तावेजीकरण करना कि क्या उपयोगकर्ता के पास वैध सदस्यता है या नहीं, इसकी बहुत सराहना की जाएगी। मैं

curiousdustin 25 अक्तू॰ 2018

यदि आप माध्यम का संदर्भ लेते हैं तो @curiousdustin इस पर Apple का कार्यान्वयन वास्तव में भयानक है। चूंकि आपको अपने बैकएंड में इस तरह की चीजों को संभालने की जरूरत है, इसलिए हम अपने मॉड्यूल में इसका पूरी तरह से समर्थन नहीं कर सके। हालाँकि, आप हमारी पद्धति getAvailablePurchases का उपयोग करके Android में availablePurchases प्राप्त कर सकते हैं जो ios सदस्यता उत्पाद पर काम नहीं करेगा।

hyochan 25 अक्तू॰ 2018

तो क्या आप समाधान कह रहे हैं कि @marcosmartinez7 और @kevinEsherick इस धागे में काम कर रहे हैं, यह कोई समाधान नहीं है, और यह कि Apple के अलावा एक बैकएंड सर्वर iOS सदस्यता की स्थिति की पुष्टि करने के लिए आवश्यक है?

Apple डॉक्स के साथ आपके द्वारा पोस्ट किए गए माध्यम लेख को पढ़ने से, ऐसा लगता है कि सर्वर का उपयोग करना पसंद किया जाता है, लेकिन केवल डिवाइस के साथ सदस्यता की स्थिति निर्धारित करना असंभव नहीं है।

curiousdustin 25 अक्तू॰ 2018

👍1

क्षमा करें कि मेरे लेखन में कुछ जानकारी छूट गई है। मैं अब इसे मैनेज कर लूंगा।
Apple मध्य हमले से बचने के लिए अपने सर्वर में receipt को बचाने का सुझाव देता है। इसलिए आप बाद में उस रसीद की जांच कर सकते हैं कि रसीद वैध है या सदस्यता अभी भी उपलब्ध है।

हालाँकि, अभी भी react-native-iap साथ प्रयास करना असंभव नहीं है क्योंकि हम स्वयं के Apple सर्वर (सैंडबॉक्स और प्रोडक्शन) को सत्यापन रसीद का सीधा फ़ेच प्रदान करते हैं, जो शुक्र है कि @ marcosmartinez7 और @kevinEsherick ने काम किया।

मुझे लगता है कि वर्तमान में यह ios सदस्यता की जाँच के लिए काम करने का समाधान है।

hyochan 25 अक्तू॰ 2018

हे दोस्तों, क्षमा करें, कुछ दिनों से अधिक समय हो गया है, मैं काम में फंस गया हूं लेकिन मैं अभी भी उस पीआर को रीडमे को अपडेट करने के लिए जमा करूंगा। @curiousdustin जिस विधि के बारे में मैंने ऊपर लिखा है वह निश्चित रूप से काम करती है और मैं इसे डॉक्स में जोड़ दूंगा। मैं आज रात या कल पीआर जमा करूंगा :)

kevinEsherick 25 अक्तू॰ 2018

🎉1

अद्यतन धन्यवाद।

आपके उदाहरण से मैंने एक और बात देखी।

'रसीद-डेटा': खरीद [खरीदारी। लंबाई - 1]। लेनदेन रसीद,
...
कॉन्स्ट समाप्ति = नवीनीकरण इतिहास [नवीनीकरण इतिहास। लंबाई - 1]। समाप्ति_डेट_एमएस

मेरे परीक्षण में, खरीदारी और नवीनीकरण इतिहास किसी विशेष क्रम में जरूरी नहीं हैं। क्या हमें यह सत्यापित करने के लिए उन्हें या कुछ और सॉर्ट करने की आवश्यकता नहीं है कि हम उसी का उपयोग कर रहे हैं जिसका हम इरादा रखते हैं?

curiousdustin 25 अक्तू॰ 2018

👍1

मेरा भी यही विचार है। खरीद और नवीनीकरण इतिहास निश्चित रूप से आदेशित नहीं हैं, इसलिए हमें पहले क्रमबद्ध करना होगा। देव में, यह बहुत सारे पुनरावृत्तियों के रूप में समाप्त होता है।

andrewzey 27 अक्तू॰ 2018

import * as RNIap from 'react-native-iap';
import {ITUNES_CONNECT_SHARED_SECRET} from 'react-native-dotenv';

const SUBSCRIPTIONS = {
  // This is an example, we actually have this forked by iOS / Android environments
  ALL: ['monthlySubscriptionId', 'yearlySubscriptionId'],
}

async function isSubscriptionActive() {
  if (Platform.OS === 'ios') {
    const availablePurchases = await RNIap.getAvailablePurchases();
    const sortedAvailablePurchases = availablePurchases.sort(
      (a, b) => b.transactionDate - a.transactionDate
    );
    const latestAvailableReceipt = sortedAvailablePurchases[0].transactionReceipt;

    const isTestEnvironment = __DEV__;
    const decodedReceipt = await RNIap.validateReceiptIos(
      {
        'receipt-data': latestAvailableReceipt,
        password: ITUNES_CONNECT_SHARED_SECRET,
      },
      isTestEnvironment
    );
    const {latest_receipt_info: latestReceiptInfo} = decodedReceipt;
    const isSubValid = !!latestReceiptInfo.find(receipt => {
      const expirationInMilliseconds = Number(receipt.expires_date_ms);
      const nowInMilliseconds = Date.now();
      return expirationInMilliseconds > nowInMilliseconds;
    });
    return isSubValid;
  }

  if (Platform.OS === 'android') {
    // When an active subscription expires, it does not show up in
    // available purchases anymore, therefore we can use the length
    // of the availablePurchases array to determine whether or not
    // they have an active subscription.
    const availablePurchases = await RNIap.getAvailablePurchases();

    for (let i = 0; i < availablePurchases.length; i++) {
      if (SUBSCRIPTIONS.ALL.includes(availablePurchases[i].productId)) {
        return true;
      }
    }
    return false;
  }
}

andrewzey 27 अक्तू॰ 2018

👍30 🎉7 ❤3 👀2 🚀2

@andrewze

एंड्रॉइड परिदृश्य पर, यदि सदस्यता स्वतः-नवीकरणीय है, तो इसे उपलब्ध खरीद पर वापस कर दिया जाएगा

marcosmartinez7 28 अक्तू॰ 2018

@curiousdustin @andrewzey आप सही कह रहे हैं, खरीदारी का आदेश नहीं दिया गया है। नवीनीकरण इतिहास/latest_receipt_info, हालांकि, हमेशा मेरे लिए आदेश दिया जाता है। मुझे याद है कि खरीदारी का आदेश नहीं दिया गया था, लेकिन मुझे लगा कि मुझे कोई कारण मिल गया है कि यह वास्तव में चिंता का विषय नहीं था। घर पहुंचने के बाद मैं इसे कुछ घंटों में देख लूंगा। जब तक हम इसका पता नहीं लगा लेते, तब तक मैं पीआर जमा नहीं करना चाहता।
संपादित करें: तो कारण मुझे नहीं लगता कि आपको खरीदारी को सॉर्ट करने की आवश्यकता है क्योंकि समाप्ति_डेट_एमएस वही देता है चाहे आपने किस खरीद के बारे में पूछताछ की हो। क्या यह आप लोगों के लिए समान नहीं है? या क्या कुछ ऐसी जानकारी है जिसकी आपको आवश्यकता है जिसके लिए छँटाई की आवश्यकता है? मुझे अपने विचारों को जानने दें। मैं सहमत हूं कि दस्तावेज़ों को अभी भी स्पष्ट करना चाहिए कि खरीदारी कालानुक्रमिक रूप से आदेशित नहीं की जाती है, लेकिन जहां तक मैं कह सकता हूं कि समाप्ति तिथि प्राप्त करने के लिए सॉर्टिंग की आवश्यकता नहीं है।

kevinEsherick 30 अक्तू॰ 2018

@kevinEsherick धन्यवाद! मेरे मामले में, न तो खरीद और न ही नवीनीकरण इतिहास का आदेश दिया गया था।

andrewzey 30 अक्तू॰ 2018

@kevinEsherick @andrewzey क्या आप लोग इस समाधान पर PR दे सकते हैं? हम दूसरों के साथ साझा करना चाहते हैं जो पीड़ित हैं।

hyochan 3 नव॰ 2018

निश्चित रूप से हम अपने सार्वजनिक ऐप लॉन्च के साथ समाप्त होने के बाद इसे ठीक से तैयार करेंगे =)।

andrewzey 4 नव॰ 2018

मैं अपनी आखिरी टिप्पणी के बारे में और बातचीत की प्रतीक्षा कर रहा था। मैंने कुछ ऐसे मुद्दे उठाए जो अनसुलझे हैं। कृपया संदर्भ के लिए ऊपर देखें। एक बार जब हम इसे सुलझा लेते हैं तो हम में से कोई एक पीआर बना सकता है।

kevinEsherick 4 नव॰ 2018

👍1

@kevinEsherick आह क्षमा करें, मुझे वह याद आया।

प्रत्येक नवीनीकरण रसीद पर expires_date_ms निश्चित रूप से मेरे लिए अद्वितीय है। शायद मैंने गलत समझा? मैंने देखा कि प्रत्येक डीकोडेड रसीद से जुड़ी नवीनीकरण रसीद सरणी वही है, चाहे किसी भी रसीद का चयन किया गया हो, इसलिए मैं देख सकता था कि आप निम्नलिखित में सही हो सकते हैं (मेरे उदाहरण से) की आवश्यकता नहीं है:

const sortedAvailablePurchases = availablePurchases.sort(
      (a, b) => b.transactionDate - a.transactionDate
    );

लेकिन मैंने इसे वैसे भी सटीक होने की कोशिश करने की सेवा में किया, और ऐप्पल दस्तावेज़ों से वास्तविक एपीआई प्रतिक्रिया में संभावित विसंगतियों की भरपाई की। मुझे नहीं लगता कि ऑटो-नवीनीकरण सदस्यता के लिए आपको प्राप्तियों की कुल संख्या को देखते हुए एक सॉर्ट ऑपरेशन बहुत महंगा होगा।

andrewzey 4 नव॰ 2018

👍1

पीआर पर कोई ईटीए? मैं इस पैकेज से आगे बढ़ने पर विचार कर रहा हूं क्योंकि यह इस मामले को बिल्कुल भी नहीं संभालता है।

schumannd 16 नव॰ 2018

@schhumannd यह देखते हुए कि पीआर केवल डॉक्स को अपडेट करने के लिए होगा, आप अब react-native-iap हैं।

मैंने पुष्टि की है कि मेरा कोड स्निपेट वास्तव में हमारे हाल ही में लॉन्च किए गए ऐप के साथ उत्पादन में समस्या के बिना काम करता है: https://itunes.apple.com/us/app/rp-diet/id1330041267?ls=1&mt=8

संपादित करें मैं निश्चित रूप से पीआर बनाउंगा (मेरे पास हमारे ट्रेलो में "ओएसएस को वापस दें" सूची में है), लेकिन ब्लैक फ्राइडे सप्ताहांत पागलपन के बाद

andrewzey 17 नव॰ 2018

@schhumannd मैं दूसरा जो @andrewzey ने कहा। एक पीआर जो कुछ भी कहेगा वह यहां इस पोस्ट में निहित है। मैं इसके चारों ओर जाने का अर्थ रहा हूं, लेकिन हमें यह तय करने में कुछ समय लगा कि वास्तव में क्या करने की आवश्यकता है, और यात्रा और व्यस्त स्टार्टअप घंटों के साथ मिश्रित होने का मतलब है कि मेरे पास अभी तक पीआर करने का समय नहीं है। मैं अभी भी जल्द ही योजना बना रहा हूं, लेकिन अगर कोई और चाहे तो इस बीच कदम बढ़ा सकता है। और @andrewzey बधाई हो यार! बहुत अच्छा लग रहा है, मैं इसे डाउनलोड कर दूंगा!

kevinEsherick 19 नव॰ 2018

👍1

मुझे विश्वास नहीं है कि यह धागा आईओएस में ऑटो-नवीनीकरण सदस्यता को प्रबंधित करने के सही तरीके से सही तरीके से दस्तावेज करता है बल्कि इसके बजाय इस पुस्तकालय द्वारा उजागर एपीआई प्रति "वर्कअराउंड" वर्कफ़्लो का वर्णन करता है। हालाँकि, यह पूरी तरह से मेरी ओर से अटकलें हैं और मैं अच्छी तरह से जानता हूं कि मैं गलत हो सकता हूं इसलिए मैं नीचे उल्लिखित टिप्पणियों पर प्रतिक्रिया चाहता हूं।

मैं बिना किसी लाभ के रिएक्ट नेटिव में ऑटो-नवीनीकरण सब्सक्रिप्शन को प्रबंधित करने के सही तरीके पर शोध कर रहा हूं, इसलिए मैंने गियर स्विच किया और शोध करना शुरू कर दिया कि उद्देश्य-सी / स्विफ्ट में उन्हें मूल रूप से कैसे प्रबंधित किया जाए। इसने मुझे मूल StoreKit API(ओं) की तुलना करने के लिए एक संदर्भ बिंदु दिया और इस पुस्तकालय में जो लागू किया गया है, उसके उपयोग का दस्तावेजीकरण किया।

यह राइट-अप सबसे अच्छा स्पष्टीकरण है जो मैंने अब तक पाया है कि कैसे एक देशी आईओएस ऐप द्वारा सदस्यता खरीद, सत्यापन और बहाली को संभाला जाना चाहिए: https://www.raywenderlich.com/659-in-app-purchases-auto -नवीकरणीय-सदस्यता-ट्यूटोरियल और जबकि सभी एपीआई react-native-iap में उपयोग किए जा रहे हैं, वे एक अलग वर्कफ़्लो लागू कर रहे हैं।

मुझे दिखाई देने वाला एक महत्वपूर्ण अंतर appStoreReceiptUrl ।

StoreKit appStoreReceiptUrl करता है, जो मेरी समझ के अनुसार, आईओएस ऐप के लिए वर्तमान खरीद/रसीद जानकारी लोड करने का सही तरीका है। जबकि मैं इसे react-native-iap कोड में उपयोग और संदर्भित करते हुए देखता हूं, यह संदर्भित आलेख में प्रलेखित वर्कफ़्लो की तुलना में एक अलग संदर्भ में प्रतीत होता है।

मुझे यकीन नहीं है कि यह कार्यान्वयन अंतर समस्याग्रस्त है या नहीं, लेकिन react-native-iap एपीआई StoreKit के restoreCompletedTransactions पर एक असफल निर्भरता पैदा कर रहा है जिसे अंततः getPurchaseHistory कहा जाता है।

मुझे ऐसा लगता है कि react-native-iap API को iOS के लिए निम्नलिखित कार्यप्रवाह का समर्थन करना चाहिए:

एप्लिकेशन स्टार्टअप पर वर्तमान ऐप रसीद ( appStoreReceiptUrl माध्यम से) लोड करने का प्रयास करें
रसीद को मान्य करने का अवसर प्रदान करें
यदि appStoreReceiptUrl रिक्त है, तो वर्तमान डिवाइस पर एक "पुनर्स्थापना" आरंभ करें जो तब appStoreReceiptUrl का मान सेट करेगा और सत्यापन तर्क का पुन: प्रयास किया जा सकता है

हालांकि?

दोबारा, मैं इस पुस्तकालय या संदर्भित मूल कार्यान्वयन के कार्यान्वयन को गलत समझ सकता हूं।

sellmeadog 6 दिस॰ 2018

👍3 🎉2

@sellmeadog

मुझे लगता है कि आपके द्वारा लिंक किए गए आलेख में भी एक महत्वपूर्ण बिंदु का उल्लेख किया गया है:

नोट: प्रोजेक्ट ऐप सेल्फी सेवा चलाता है, जो रसीदों को स्वीकार करता है और उन्हें सीधे ऐप्पल की रसीद सत्यापन सेवा पर अपलोड करता है। यह सब्सक्रिप्शन सेट करने पर ट्यूटोरियल को केंद्रित रखने के लिए एक "धोखा" है। एक वास्तविक ऐप में, आपको इसके लिए रिमोट सर्वर का उपयोग करना चाहिए - ऐप नहीं।

मुझे पूरी ऑटो-नवीकरणीय सदस्यता का पता लगाने में कुछ समय लगा, लेकिन मैं इसे संभालने का सबसे अच्छा तरीका समझता हूं कि सत्य के एकल स्रोत के रूप में अपने स्वयं के बैकएंड का उपयोग कर रहा हूं:

सभी लेन-देन डेटा तुरंत अपने बैकएंड पर भेजें
ट्रांसमिशन की समस्या के मामले में फिर से भेजने के कुछ साधन प्रदान करें (उदाहरण के लिए खरीद बहाल करना)
समय-समय पर (उदाहरण के लिए दिन में एक बार) अपने बैकएंड पर सभी संग्रहीत रसीदों को सत्यापित करें
सदस्यता स्थिति के लिए ऐप क्वेरी बैकएंड जैसे पृष्ठभूमि से वापसी।

यह मुझे सब्सक्रिप्शन को संभालने का एकमात्र समझदार तरीका लग रहा था। मैंने कुछ समय के लिए व्यावसायिक रूप से ऑटो-नवीकरणीय सदस्यता का उपयोग करके अन्य देवों के साथ इस प्रक्रिया को सत्यापित किया है।

तो ओपीएस प्रश्न का मेरा उत्तर होगा: बैकएंड में समय-समय पर सदस्यता की जांच करें, न कि दृश्यपटल में

schumannd 13 दिस॰ 2018

❤1 🎉1 😄1 👍1

@shumannd

मुझे यकीन नहीं है कि हम एक ही मुद्दे को समझ रहे हैं या बात कर रहे हैं।

रसीद सत्यापन सर्वर पर किया जाना चाहिए। ऐप्पल के अपने दस्तावेज़ीकरण के अनुसार :

अपने ऐप से ऐप स्टोर सर्वर /verifyReceipt एंडपॉइंट को कॉल न करें।

मैंने संदर्भित आलेख में "धोखा" की व्याख्या विशेष रूप से नमूना ऐप की सीधी कॉल /verifyReceipt सीधे ऐप से बैकएंड सर्वर को सौंपने के बजाय संक्षिप्तता के लिए की है।

मुझे ऐसा लगता है कि ऐप्पल/ऐप स्टोर सत्य का एकमात्र स्रोत है और होना चाहिए। Apple अंततः खरीद, नवीनीकरण, रद्दीकरण आदि को संसाधित कर रहा है और तदनुसार रसीदें उत्पन्न कर रहा है और उस डेटा को StoreKit API के माध्यम से उपलब्ध कराता है।

react-native-iap बिना किसी समस्या के खरीद और पुनर्स्थापना खरीद को संभालता है, लेकिन मुझे अभी भी लगता है कि ऐप स्टोर रसीद डेटा तक पहुंचने में एक अंतर है जो स्थानीय रूप से appStoreReceiptUrl पर उपलब्ध कराया जाता है जो कि रसीद तक पहुंचने का ऐप्पल का दस्तावेज तरीका है डेटा :

रसीद डेटा पुनर्प्राप्त करने के लिए, ऐप की रसीद का पता लगाने के लिए appStoreReceiptURL पद्धति का उपयोग करें NSBundle ...

ऐप्पल दस्तावेज़ों के माध्यम से पढ़ने और मूल ऑब्जेक्ट-सी/स्विफ्ट कार्यान्वयन को संदर्भित करने से मैं जो वर्कफ़्लो समझता हूं वह निम्नानुसार है:

खरीद के लिए उत्पादों को लोड करें
एक उत्पाद खरीदें (उपभोज्य, गैर-उपभोज्य, सदस्यता, कोई फर्क नहीं पड़ता)
उस खरीद के लिए रसीद स्थानीय रूप से appStoreReceiptUrl द्वारा StoreKit परदे के पीछे संग्रहीत की जाती है
आवश्यकता के अनुसार सत्यापन के लिए ऐप को बैकएंड सर्वर पर रसीद डेटा भेजना चाहिए (सीधे ऐप स्टोर /verifyReceipt )
रद्दीकरण और/या नवीनीकरण होने पर appStoreReceiptUrl को StoreKit द्वारा अपडेट किया जाता है (यह मानते हुए कि उचित StoreKit प्रतिनिधि सही तरीके से पंजीकृत हैं)
जब appStoreReceiptUrl शून्य हो, क्योंकि उपयोगकर्ता एक नए डिवाइस पर है, आदि, पुनर्स्थापना खरीद वर्कफ़्लो का उपयोग करें जो ऐप्पल / ऐपस्टोर से वर्तमान रसीद डेटा पुनर्प्राप्त करेगा और StoreKit इसे स्थानीय रूप से appStoreReceiptUrl पर बनाए रखेगा

फिर, react-native-iap हैंडल इस सब से लोड हो रहा है रसीद डेटा के अलावा appStoreReceiptUrl । मुझे लगता है कि स्थानीय रसीद के लिए पूछे जाने वाले getReceipt विधि से सदस्यता और/या किसी भी अन्य खरीद के प्रबंधन का बोझ कम हो जाएगा।

Apple ने इसके बारे में तर्क करना जितना होना चाहिए था, उससे कहीं अधिक कठिन बना दिया है।

sellmeadog 13 दिस॰ 2018

appStoreReceiptUrl को StoreKit द्वारा अपडेट किया जाता है जब भी रद्दीकरण और/या नवीनीकरण होता है (यह मानते हुए कि उचित StoreKit प्रतिनिधि सही तरीके से पंजीकृत हैं)

यह इस दृष्टिकोण के साथ मेरी समस्या का वर्णन करता है: आपको किसी भी नवीनीकरण / रद्दीकरण / समाप्ति आदि की सूचना नहीं मिलती है। यदि उपयोगकर्ता आपके ऐप को बाद में एक काम कर रहे इंटरनेट कनेक्शन के साथ नहीं खोलता है।

इसके अलावा, यह मेरे द्वारा वर्णित दृष्टिकोण के लिए एक अच्छा विकल्प प्रतीत होता है। मुझे आश्चर्य है कि उत्पादन ऐप्स के लिए किसका सबसे अधिक उपयोग किया जाता है।

schumannd 17 दिस॰ 2018

@sellmeadog मुझे लगता है कि यह वही विचार है जिसे मैंने यहां पोस्ट किया है: #356
स्थानीय स्तर पर रसीदों को मान्य करना एक तरीका है, सेब अनुशंसा करता है। यह किसी भी सर्वर/नेटवर्क अनुरोध से पूरी तरह से स्वतंत्र है।

हां। "कोई नेटवर्क कनेक्शन नहीं - कोई सत्यापन नहीं" के संबंध में डाउनसाइड्स हैं।
लेकिन इसके लिए उपयोग के मामले हैं।
मैं प्रत्येक ऐप लॉन्च पर रसीद का तेज़ सत्यापन चाहता हूं और UserDefaults या Keychain माध्यम से इन-ऐप खरीदारी के बारे में ट्रैक नहीं रखना चाहता हूं। StoreKit पहले से ही एक भंडारण तंत्र प्रदान करता है।

Purii 4 जन॰ 2019

👍1

आपको कैसे जांचना चाहिए कि IOS उपयोगकर्ता ने getAvailablePurchases जैसी किसी चीज़ के माध्यम से iTunes खाते में लॉगिन करने के लिए उन्हें संकेत दिए बिना अपनी सदस्यता को नवीनीकृत या रद्द कर दिया है या नहीं?

उदाहरण के लिए:
सदस्यता की पहली खरीद पर, हम रसीद को मान्य करते हैं और समाप्ति तिथि को उनके फायरबेस प्रोफ़ाइल में सहेजते हैं। हम उस फ़ायरबेस नोड का उपयोग स्टार्ट-अप पर जाँच करने के लिए करते हैं कि क्या उनके पास सक्रिय सदस्यता है। समस्या तब आती है जब वह समाप्ति तिथि बीत जाती है और नई बिलिंग अवधि शुरू हो जाती है। हम यह देखने के लिए कैसे जांच सकते हैं कि वे स्वतः नवीनीकृत या रद्द हो गए हैं? जैसा कि उल्लेख किया गया है, हम getAvailablePurchases का उपयोग कर रहे थे, लेकिन यह आईट्यून्स लॉगिन को एक पुनर्स्थापना बटन की तरह संकेत देता है - जो भयानक यूआई है

csumrell 18 जन॰ 2019

👍1

मुझे भी यही बात आश्चर्य है।

हमारे ऐप में हमें इसकी आवश्यकता नहीं है, क्योंकि हमारे पास एक सर्वर साइड एपीआई है जो स्थिति की जांच करने के लिए सीधे ऐप्पल के साथ संचार करता है। मूल खरीद के बाद, रसीद डेटा हमारे सर्वर पर संग्रहीत किया जाता है, और फिर बाद में अद्यतन स्थिति के लिए पूछने के लिए उपयोग किया जाता है।

हालाँकि, मेरा मानना है कि यह अभी भी डिवाइस की तरफ से संभव होना चाहिए। मैं इस पर एक विशेषज्ञ नहीं हूं, लेकिन जिस तरह से मैं इसे समझता हूं, जब भी कोई नवीनीकरण होता है तो ऐप को ओएस से एक अद्यतन लेनदेन/रसीद प्राप्त होगी। मुझे संदेह है कि यह प्लगइन ऐप लॉन्च पर इन रसीदों को संभाल रहा है। (एक्सकोड से चलते समय मुझे लॉग का एक गुच्छा दिखाई देता है, जो कई लेनदेन को संसाधित करता प्रतीत होता है) लेकिन, जो मैं बता सकता हूं, जेएस कोड में उन घटनाओं में टैप करने का कोई तरीका नहीं है।

क्या हमें इसके बारे में कुछ और जानकारी मिल सकती है?

curiousdustin 18 जन॰ 2019

👍1

@csumrell @curiousdustin क्या आप लोगों के पास उत्पादन वातावरण में इस व्यवहार की पुष्टि है? मैं सोच रहा हूं कि क्या यह सैंडबॉक्सिंग के कारण हो सकता है, सैंडबॉक्स खाते के साथ साइन इन करने की आवश्यकता है क्योंकि संभवतः आपके डिवाइस पर एक और, गैर-सैंडबॉक्स खाता है, जबकि उत्पादन में उपयोगकर्ता को संभवतः उनके सामान्य खाते में साइन इन किया जाएगा और यह मॉड्यूल लॉगिन का संकेत दिए बिना खरीद प्राप्त करने में सक्षम हो सकता है।

kevinEsherick 25 जन॰ 2019

क्षमा करें, मैंने पुष्टि नहीं की है कि getAvailablePurchases() उत्पादन में पासवर्ड संकेत देता है।

मैंने अभी यह मान लिया है क्योंकि डॉक्स इस पद्धति के बारे में बात करते हैं जिसका उपयोग आमतौर पर रिस्टोरिंग परचेज के रूप में संदर्भित सुविधा के लिए किया जाता है, जिसमें मेरे अनुभव में प्रमाणीकरण शामिल है, कम से कम आईओएस पर।

@Hyochan @JJMoon क्या हमें इस बारे में और जानकारी भी मिल सकती है? विशेष रूप से, प्रमाणीकरण का प्रयास करने के लिए ओएस को ट्रिगर किए बिना विश्वसनीय रूप से उपलब्ध या ऐतिहासिक खरीदारी प्राप्त करने का कोई तरीका है? ऐप लॉन्च पर खोजी और संसाधित की गई खरीदारी पर प्रतिक्रिया करने की क्षमता के संबंध में, कृपया मेरे प्रश्न 2 टिप्पणियों को ऊपर देखें।

curiousdustin 25 जन॰ 2019

@curiousdustin हाँ, इसलिए जब मैं अपने सामान्य iTunes खाते से और सैंडबॉक्स खाते से साइन आउट करता हूं तो यह मुझे इस विधि को कॉल करने पर लॉगिन करने के लिए प्रेरित नहीं करता है। तो मेरा अनुमान/आशा है कि उत्पादन में, जहां उपयोगकर्ताओं के पास उपयोग में सैंडबॉक्स खाता नहीं है, समस्या पॉप अप नहीं होनी चाहिए। बीटा परीक्षण उसी तरह काम करना चाहिए जैसे उत्पादन बीसी उपयोगकर्ताओं के पास डिवाइस पर सैंडबॉक्स खाते नहीं हैं, यह केवल विकास उपकरणों की समस्या है। इसलिए मैं कल बीटा उपयोगकर्ताओं के साथ इसका परीक्षण करने जा रहा हूं और आपको बताऊंगा कि मुझे क्या मिला।
संपादित करें: मैं पुष्टि कर सकता हूं कि यह गैर-सैंडबॉक्स उपकरणों पर होता है। यह भयानक यूएक्स है और काफी समस्याग्रस्त है। कोई भी, कोई विचार?

kevinEsherick 26 जन॰ 2019

इसलिए जब आप अपने ऐप से ऐप स्टोर सर्वर/verifyReceipt एंडपॉइंट पर कॉल करके अपने सर्वर पर सत्यापन करते हैं, तो यह हमेशा उस उपयोगकर्ता के लिए नवीनतम अपडेट टू डेट जानकारी केवल मूल पहली खरीद रसीद के साथ लौटाएगा।

क्या किसी को पता है कि स्थानीय वैध विधि का उपयोग करने से हमेशा सबसे अद्यतित जानकारी वापस आ जाएगी? या यह उस रसीद के लिए सख्ती से है जिसे आप स्थानीय रूप से मान्य करते हैं?

साथ ही, क्या किसी के पास ऐप्पल के साथ मान्य करने के लिए अपना सर्वर स्थापित करने की सलाह है? मुझे इसका अनुभव नहीं है

csumrell 3 फ़र॰ 2019

👍1

@csumrell आप

और मैं सर्वर पर सत्यापन के विकल्प का पता लगाने वाला हूं ताकि हम एक दूसरे की मदद कर सकें। यह सुनना अच्छा लगेगा कि कोई और इसके बारे में कैसे गया।

kevinEsherick 5 फ़र॰ 2019

@kevinEsherick हाँ लेकिन getPurchaseHistory आईट्यून्स लॉगिन पॉपअप को ट्रिगर करेगा। जब उपयोगकर्ता पहली बार खरीदारी करता है तो मैं मूल रसीद को स्थानीय संग्रहण में सहेजने के बारे में बात कर रहा हूं। फिर अगली बिलिंग की जांच करने के लिए getPurchaseHistory को कॉल करने के बजाय, वैलिडेट रिसीप्टआईओएस (ओरिजिनल रिसीप्ट) को कॉल करें जो स्थानीय रूप से मान्य है। हालांकि, मुझे यकीन नहीं है कि अगर मान्य रसीदआईओएस ऐप्पल सर्वर/सत्यापन रसीद की तरह अद्यतित लेनदेन लौटाता है

csumrell 5 फ़र॰ 2019

@csumrell गोचा । वैसे यह जल्दी और आसानी से परीक्षण योग्य है। क्या आपने कोशिश नहीं की? यदि नहीं, तो मैं आज बाद में इसकी जाँच करूँगा।
संपादित करें: @csumrellValidReceiptIos वास्तव में उस खरीद पर नवीनतम ऑटोरिन्यूअल को ट्रैक करता है, इसलिए यह एक वैध तरीका है। मैं कहूंगा कि यह सब्सक्रिप्शन की जाँच के लिए उपरोक्त प्रस्तावित तरीकों से बेहतर है क्योंकि यह आईट्यून्स लॉगिन प्रॉम्प्ट से बचता है (जब तक कि कोई इसके लिए एक फिक्स के साथ नहीं आ सकता)। दोष यह है कि आपको रसीदों को स्थानीय रूप से संग्रहीत करना होगा। यह बहुत अधिक परेशानी नहीं होनी चाहिए। इसके अलावा, आप सुरक्षा कारणों से इन रसीदों को आपके बैकएंड पर नहीं जाना चाहते हैं या तथ्य यह है कि वे बड़े पैमाने पर (~ 60k वर्ण) हैं, तो इसका मतलब यह होगा कि यदि कोई सब्सक्राइब किया गया उपयोगकर्ता साइन आउट करता है या किसी नए डिवाइस का उपयोग करना शुरू करता है तो आपको इसकी आवश्यकता होगी उन्हें अपनी नवीनतम खरीद रसीद प्राप्त करने के लिए लॉगिन करने के लिए प्रेरित करें। आप उनकी सदस्यता स्थिति को आंतरिक रूप से संग्रहीत कर सकते हैं ताकि आप केवल उन उपयोगकर्ताओं को संकेत दें जिन्हें आपने अंतिम बार चेक किया था।

kevinEsherick 5 फ़र॰ 2019

@hyochan ने इस मुद्दे पर $20.00 का वित्त पोषण किया है। इसे इश्यूहंट पर देखें

IssueHuntBot 7 फ़र॰ 2019

@hyochan आप किस विशिष्ट समाधान के लिए फंडिंग कर रहे हैं? हमने यहां इस धागे में कुछ प्रदान किए हैं, और मुझे लगता है कि मेरी नवीनतम टिप्पणी सबसे कम मुद्दों के साथ सबसे मजबूत समाधान प्रदान करती है। क्या आप इन समाधानों को एक संक्षिप्त पीआर में पढ़ने के लिए किसी को धन दे रहे हैं? या यह कोई वास्तविक कोड समस्या है जिसे आप अभी भी हल करना चाहते हैं?

kevinEsherick 7 फ़र॰ 2019

@केविनएशेरिक

क्या आप इन समाधानों को एक संक्षिप्त पीआर में पढ़ने के लिए किसी को धन दे रहे हैं?

हां। यह बिल्कुल सही है। इसके अलावा, मैं सिर्फ यह जांचना चाहता था कि कैसे issue hunt बॉक्स से बाहर काम कर सकता है। मेरी अगली योजना टेस्ट केस बनाने के लिए फंडिंग करना है।

hyochan 7 फ़र॰ 2019

🎉1

@kevinEsherick आप सही हैं,

मैं अपने स्वयं के सर्वर को स्थापित करने से बचने के लिए और सदस्यता सक्रिय है या नहीं, यह जाँचते समय आईट्यून्स लॉगिन पॉपअप से बचने के लिए इस पद्धति का उपयोग करूँगा।

csumrell 12 फ़र॰ 2019

इस सत्यापन प्रवाह का उपयोग करने पर विचार करने वालों के लिए एक नोट जो @csumrell और मैंने निर्धारित किया है: मैंने पाया है कि विकास में आईट्यून्स लॉगिन प्रॉम्प्ट अभी भी पहले लॉन्च पर पॉप अप कर रहा है। उत्पादन में ऐसा नहीं होता है। जब तक आप हमारे द्वारा निर्धारित चरणों का पालन कर रहे हैं, तब तक सब ठीक होना चाहिए। यह ऐसा क्यों कर रहा है, शायद जब आईओएस देखता है कि आईएपी का उपयोग किया जा रहा है/विकास में मॉड्यूल मानचित्र का हिस्सा है तो यह स्वचालित रूप से साइन इन करने का संकेत देता है। मुझे पूरा यकीन नहीं है, लेकिन ऐसा लगता है कि यह सिर्फ सैंडबॉक्स परीक्षण की एक विशेषता है।

kevinEsherick 13 फ़र॰ 2019

❤5

अरे, ऐसा लगता है कि हाल ही में इस मुद्दे पर कोई गतिविधि नहीं हुई है। क्या समस्या का समाधान कर दिया गया है, या क्या इस पर अभी भी समुदाय के ध्यान की आवश्यकता है? यदि आगे कोई गतिविधि नहीं होती है, तो यह समस्या बंद हो सकती है। आप इस मुद्दे को "चर्चा के लिए" या "अच्छा पहला अंक" के रूप में भी लेबल कर सकते हैं और मैं इसे खुला छोड़ दूंगा। आपके योगदानों के लिए धन्यवाद।

stale[bot] 23 मई 2019

लंबे समय तक निष्क्रियता के बाद इस मुद्दे को बंद करना। यदि यह समस्या अभी भी नवीनतम रिलीज़ में मौजूद है, तो कृपया अप-टू-डेट जानकारी के साथ एक नया मुद्दा बनाने के लिए स्वतंत्र महसूस करें।

stale[bot] 22 जून 2019

शायद इस पूरे प्रवाह को दस्तावेज़ीकरण में स्पष्टीकरण की आवश्यकता है?

खासकर जब ऑटो-नवीनीकरण सदस्यता की बात आती है? एक नवागंतुक के लिए यह बहुत अस्पष्ट है कि क्या आप expires_date_ms जांच करने में सक्षम हैं कि सदस्यता अभी भी सक्रिय है या नहीं?

मेरा सुझाव है कि इसके लिए सबसे अच्छी जगह एक अधिक पूर्ण कार्य उदाहरण में होगी?

क्या इसमें लोगों की दिलचस्पी होगी? अगर मुझे कुछ समय मिले तो क्या मैं इस पर काम कर सकता हूँ?

alexpchin 24 सित॰ 2019

👍13

@alexpchin हाँ यह निश्चित रूप से एक टन देव समय बचाएगा और आपके कर्म क्रिस्टल साफ हो जाएंगे

albertkai 16 नव॰ 2019

सहमत! क्या किसी को #856 में दिलचस्पी होगी?

hyochan 17 नव॰ 2019

नमस्ते,

@andrewzey की विधि ने कल तक हमारे लिए बहुत अच्छा काम किया है जब हम अचानक हमारे सब्सक्रिप्शन के लिए किसी भी रसीद को सत्यापित नहीं कर रहे थे - हमें वैधReceiptIos() को कॉल करते समय आईओएस से JSON पार्स त्रुटि वापस मिल रही है। मैं इसे लेता हूँ कोई और इसमें नहीं भागा है...? कल के बाद से जो एकमात्र बदलाव किया गया था, वह आईटीसी पर एक प्रोमो कोड को जोड़ना था जिसे हमने तब से हटा दिया है ताकि चर को खत्म करने में मदद मिल सके। क्या कोई कारण है कि रसीद JSON पार्सिंग में विफल होनी चाहिए? यह लौटाई गई प्रत्येक रसीद के लिए विफल रहता है - न कि केवल क्रमबद्ध उपलब्ध खरीद के सूचकांक 0 पर रसीद। कोड मूल रूप से एंड्रयूजी के उदाहरण के समान है - मैंने वैध रसीद के बाद सब कुछ छोड़ दिया है क्योंकि त्रुटि वहां फेंक दी गई है।

हम RN 0.61.4, RNIap: 4.4.2 और iOS 13.3.1 चला रहे हैं

हमने कोशिश की है:

ऐप को फिर से इंस्टॉल करना
नया उपयोगकर्ता खाता
एक नए ऐप सीक्रेट का उपयोग करना
प्रत्येक उपयोगकर्ता पर सभी रसीदों का परीक्षण - एक भी रसीद को पार्स नहीं किया जा सकता

हम सोच रहे हैं कि क्या जब हम सैंडबॉक्स खरीदारी करते हैं तो क्या हम फिनिशट्रांसेक्शनआईओएस का सही उपयोग नहीं कर रहे थे?

वास्तव में अजीब बात यह है कि जब हम इस ऑनलाइन टूल का उपयोग करके रसीद को मान्य करते हैं, तो सब कुछ सामान्य दिखता है और हम सभी रसीद मेटाडेटा देख सकते हैं।

  isSubscriptionActive = async () => {
      const availablePurchases = await RNIap.getAvailablePurchases();
      const sortedAvailablePurchases = availablePurchases.sort(
        (a, b) => b.transactionDate - a.transactionDate
      );
      const latestAvailableReceipt = sortedAvailablePurchases[0].transactionReceipt;
      const isTestEnvironment = __DEV__;

      try {
        const decodedReceipt = await RNIap.validateReceiptIos(
          {
            'receipt-data': latestAvailableReceipt,
            password: Config.IN_APP_PURCHASE_SECRET,
          },
          isTestEnvironment
        );
        console.log('response!', decodedReceipt)
      } catch (error) {
        console.warn('Error validating receipt', error) // JSON PARSE ERROR HERE
      }
...

Recover-Athletics 28 फ़र॰ 2020

@andrewzey कोड के संबंध में प्रश्न रखा गया है। क्या Date.now() वर्तमान डिवाइस समय नहीं होगा और एक उपयोगकर्ता संभवतः इसे बदल सकता है और एक अंतहीन सदस्यता प्राप्त कर सकता है? मैं

साथ ही, क्या ऐप से रसीद की पुष्टि करना ही हतोत्साहित नहीं है?

doteric 11 मई 2020

👀2 👍2

@doteric क्या आप मुझे इंगित कर सकते हैं कि वे इसके निराश होने का उल्लेख कहां करते हैं? मुझे पता है कि आप सर्वर साइड नोटिफिकेशन सेट कर सकते हैं, लेकिन सर्वर के बजाय क्लाइंट पर इस सत्यापन को संभालना मेरे दृष्टिकोण से बहुत आसान लगता है।
मैं सेब या अन्य ठोस प्रतिक्रिया देशी स्रोतों से सही दस्तावेज खोजने के लिए संघर्ष कर रहा हूं।

captaincole 29 जून 2020

@doteric Yes Date.now() डिवाइस का समय है इसलिए इसे चारों ओर काम किया जा सकता है। फिर भी एक उपयोगकर्ता के ऐसा करने की संभावना बहुत कम है, और अंतहीन सदस्यता के लिए अन्य तरीकों पर भी काम किया जा सकता है। उदाहरण के लिए यदि एक साधारण सर्वर साइड सत्यापन का उपयोग कर रहे हैं, तो वे ऐप को खोलने से पहले हवाई जहाज मोड में प्रवेश कर सकते हैं ताकि ऐप को यह महसूस करने से रोका जा सके कि सदस्यता समाप्त हो गई है। निश्चित रूप से अन्य सुरक्षा भी हैं जिन्हें आप लागू कर सकते हैं, लेकिन मेरा कहना है कि दिनांक.अब () का उपयोग करने वाला क्लाइंट पक्ष निश्चित रूप से कार्यात्मक है। @captaincole मेरे पास दस्तावेज़ नहीं हैं लेकिन मैं पुष्टि कर सकता हूं कि मैंने भी पढ़ा है कि क्लाइंट साइड सत्यापन निराश है। मैंने इसे ऐप्पल दस्तावेज़ों में पढ़ा है, मुझे विश्वास है। ऐसा कहा जा रहा है, मुझे लगता है कि ग्राहक पक्ष काम पूरा कर लेता है।

kevinEsherick 30 जून 2020

👍1

@kevinEsherick @captaincole

आईओएस पर क्लाइंट-साइड रसीद सत्यापन के बारे में:

acostalima 30 जून 2020

👍1

नमस्ते,

मैं इस धागे में चर्चा किए गए दृष्टिकोणों में से एक का प्रयास कर रहा था, मान्य रसीद Ios और नवीनतम_receipt_data (वास्तविक तिथि के साथ समाप्ति_डेट_एमएस की तुलना) का उपयोग करके। एक्सकोड में विकास करते समय इसने बहुत अच्छा काम किया। हालाँकि, जब मैंने टेस्टफ्लाइट में इसका परीक्षण किया तो यह काम नहीं किया। डीबग करना मुश्किल है इसलिए मैं सटीक समस्या की पहचान करने में सक्षम नहीं हूं, ऐसा लगता है कि इसे रसीद डेटा नहीं मिल रहा है। क्या किसी के पास टेस्टफ्लाइट के साथ भी ऐसा ही मुद्दा था?

अग्रिम में धन्यवाद!

asobralr 15 जुल॰ 2020

नमस्ते,
मैं इस धागे में चर्चा किए गए दृष्टिकोणों में से एक का प्रयास कर रहा था, मान्य रसीद Ios और नवीनतम_receipt_data (वास्तविक तिथि के साथ समाप्ति_डेट_एमएस की तुलना) का उपयोग करके। एक्सकोड में विकास करते समय इसने बहुत अच्छा काम किया। हालाँकि, जब मैंने टेस्टफ्लाइट में इसका परीक्षण किया तो यह काम नहीं किया। डीबग करना मुश्किल है इसलिए मैं सटीक समस्या की पहचान करने में सक्षम नहीं हूं, ऐसा लगता है कि इसे रसीद डेटा नहीं मिल रहा है। क्या किसी के पास टेस्टफ्लाइट के साथ भी ऐसा ही मुद्दा था?
अग्रिम में धन्यवाद!

Somnus007 18 अग॰ 2020

@asobralr @ Somnus007 मैं गलत हो सकता हूं, लेकिन मुझे नहीं लगता कि आप टेस्टफ्लाइट के साथ आईएपी का परीक्षण कर सकते हैं क्योंकि उपयोगकर्ता टेस्टफलाइट के माध्यम से खरीदारी नहीं कर सकते हैं। Apple उत्पादन जैसे वातावरण में ख़रीदारी के परीक्षण के लिए बढ़िया अवसर प्रदान नहीं करता है

kevinEsherick 18 अग॰ 2020

@asobralr @ Somnus007 मैं गलत हो सकता हूं, लेकिन मुझे नहीं लगता कि आप टेस्टफ्लाइट के साथ आईएपी का परीक्षण कर सकते हैं क्योंकि उपयोगकर्ता टेस्टफलाइट के माध्यम से खरीदारी नहीं कर सकते हैं। Apple उत्पादन जैसे वातावरण में ख़रीदारी के परीक्षण के लिए बढ़िया अवसर प्रदान नहीं करता है

सही। आप सैंडबॉक्स में विफलता परिदृश्यों का अनुकरण भी नहीं कर सकते, जो शर्म की बात है। मैं

acostalima 21 अग॰ 2020

हाय @kevinEsherick , आपके उत्तर के लिए धन्यवाद। आप गलत हो सकते हैं। उपयोगकर्ता teslflight के माध्यम से खरीदारी कर सकता है। टेस्टफ्लाइट पर, ऐसा लगता है कि उपयोगकर्ता को एक सैंडबॉक्स खाते में प्रवेश करना है, जिसमें उसके असली सेब खाते के साथ एक ही ईमेल पता है। तब सब कुछ अच्छा काम करता है। बीटीडब्लू, क्या खरीद इतिहास उत्पादन एनवी में आईट्यून्स लॉगिन पॉपअप ट्रिगर करेगा?

Somnus007 24 अग॰ 2020

ऐसा लगता है कि ios 14 इस समाधान को इस तथ्य के कारण तोड़ता है कि जब आप कॉल करने से पहले getAvailablePurchases() को कॉल करते हैं तो समस्याएँ होती हैं।

the-dut 24 सित॰ 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

React-native-iap: IOS जाँचता है कि क्या स्वतः नवीनीकरण सदस्यता अभी भी सक्रिय है

प्रतिक्रिया देशी-आईएपी . का संस्करण

जिन प्लेटफार्मों में आपको त्रुटि का सामना करना पड़ा (आईओएस या एंड्रॉइड या दोनों?)

अपेक्षित् व्यवहार

वास्तविक व्यवहार

सबसे उपयोगी टिप्पणी

सभी 61 टिप्पणियाँ

203 #237

संबंधित मुद्दों