나도 이것을 알아내기 위해 노력하고 있다. 아직 테스트하지 않았지만 내가 읽은 내용에서 iTunes Connect에서 "공유 비밀"을 만들고 '비밀번호' 키를 사용하여 이를 validateReceiptIos에 전달하면 가능하다는 것을 수집하고 있습니다. 그러면 구독의 유효성 검사 상태를 나타내는 코드와 특히 구독 상태를 확인하는 데 사용할 수 있는 latest_receipt, latest_receipt_info 및 latest_expired_receipt 정보가 포함된 JSON 개체가 반환될 것이라고 생각합니다. 나는 문자 그대로 이것을 알아 내고 있으므로 아직 테스트하지 않았습니다. 문제와 Apple의 문서를 모아 놓은 것입니다. 이것이 효과가 있다면 문제에 묻히지 않고 문서에서 매우 명확하게 밝혀야 합니다.
다음 링크가 관련이 있다고 생각합니다.
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

훌륭한!

귀하의 코드에 대해 그다지 사소하지 않은 몇 가지 사항;

1. 그것은해야한다

const 만료 = 갱신 기록 [renewalHistory.length - 1].expires_date_ms

대신 (아마도 그냥 오타)

const 만료 = latestRenewalReceipt [latestRenewal.length - 1].expires_date_ms

2) '비밀번호'가 무엇인지 모르는 분들을 위해: '비밀번호가 무엇이든':

인앱 페이지에 대한 공유 비밀 키를 만들고 앱에서 사용할 수 있습니다.

단계는 다음과 같습니다. https://www.appypie.com/faqs/how-can-i-get-shared-secret-key-for-in-app-purchase

+1 문서 업데이트, 또한 @dooboolab IOS와 Android에서 사용 사례를 분리할 수 있으며 몇 가지 다른 점이 있는 것 같습니다. 원하시면 도와드릴 수 있습니다.

문안 인사

@kevinEsherick

자동 갱신 구독은 어떻게 됩니까?

expires_date_ms가 첫 번째 만료 날짜인 것 같으며 업데이트되지 않았습니다.

나는 이것을 테스트했다 :

1. 구독 항목 구독
2. 만료 날짜 확인(예: 5분 후)
3. 10분 기다려
4. 구독이 여전히 활성 상태인 것 같습니다. 자동 갱신 구독입니다.
5. 마지막 갱신 영수증 만료를 확인하면 여전히 포인트 2와 동일합니다.

어떤 아이디어?

내 나쁜, 만료 날짜가 업데이트 된 것 같습니다. 단지 시간이 걸립니다.

누군가가 같은 시나리오에 있는 경우를 대비하여 여기에 이 ​​의견을 남길 것입니다.

문안 인사

1. 그것은해야한다

const 만료 = 갱신 기록 [renewalHistory.length - 1].expires_date_ms

대신 (아마도 그냥 오타)

const 만료 = latestRenewalReceipt [latestRenewal.length - 1].expires_date_ms

아 맞다, 오타가 맞았다. 그 의미를 더 명확하게 하기 위해 이름을 변경했지만 모든 항목을 변경하는 것을 잊었습니다. 수정했습니다, 감사합니다.

그리고 만료 날짜가 있는 정확한 시나리오는 없었지만 자동 갱신이 전혀 되지 않는 일부 항목이 있었지만 자체적으로 해결되었습니다(걱정되지만 재생산할 수 없으므로 다른 작업을 수행해야 함). 당신이 가진 문제는 상당히 일반적인 문제입니다. Apple 측에서 예상한 동작이므로 사용자를 구독 취소하기 전에 구독이 갱신될 수 있도록 버퍼 기간을 남겨 두어야 합니다. SO에 대한 이 문제는 https://stackoverflow.com/questions/42158460/autorenewable-subscription-iap-renewing-after-expiry-date-in-sandbox 에서 자세히 설명합니다.

감사 해요! 좋은 정보, 이유가 될 수 있습니다

이 문제에 대해 @kevinEsherick 코드가 문서에 있어야 한다고 생각합니다

예. PR 요청하는 사람이 있으면 readme 의 깔끔한 문서를 보내주시면 감사하겠습니다. 감사 해요.

안녕 얘들아. Readme에 Q & A 섹션 을 추가했습니다. 누구든지 이 문제에 대해 PR 를 제공할 수 있기를 바랍니다.

며칠 내로 PR을 할 수 있도록 노력하겠습니다. :)

나는 또한 특히 구독을 위해 이 라이브러리를 사용하려고 합니다. iOS와 안드로이드 모두. 사용자에게 유효한 구독이 있는지 확인하는 적절한 방법을 문서화하면 대단히 감사하겠습니다. 😄

@curiousdustin 이에 대한 Apple의 구현은 medium 을 참조하면 정말 끔찍합니다. 백엔드에서 이러한 종류의 작업을 처리해야 하므로 모듈에서 이를 완전히 지원할 수 없습니다. 그러나 iOS 구독 제품에서는 작동하지 않는 getAvailablePurchases 방법을 사용하여 Android에서 availablePurchases 를 얻을 수 있습니다.

그래서 @marcosmartinez7 과 @kevinEsherick 이 이 스레드에서 작업하고 있는 솔루션이 솔루션이 아니며 iOS 구독 상태를 확인하기 위해 Apple 이외의 백엔드 서버가 필요하다는 신가요 ?

Apple 문서와 함께 게시한 Medium 기사를 보면 서버를 사용하는 것이 선호되는 것 같지만 장치만으로 구독 상태를 확인하는 것이 불가능한 것은 아닙니다.

제 글에 정보가 누락된 점 죄송합니다. 지금 관리하겠습니다.
Apple 는 중간 공격을 방지하기 위해 receipt 를 자신의 서버에 저장하는 것을 제안합니다. 따라서 나중에 영수증을 확인하여 영수증이 유효한지 또는 구독을 계속 사용할 수 있는지 확인할 수 있습니다.

그러나 감사하게도 @marcosmartinez7 과 @kevinEsherick이 해결한 자체 Apple 서버(샌드박스 및 프로덕션)에 검증 영수증의 직접 가져오기를 제공하기 때문에 react-native-iap 로 계속 시도하는 것은 불가능하지 않습니다.

현재 이것이 ios 구독을 확인하기 위한 해결 방법이라고 생각합니다.

안녕하세요, 죄송합니다. 며칠 이상 지났습니다. 일에 몰두했지만 여전히 README를 업데이트하기 위해 해당 PR을 제출할 것입니다. @curiousdustin 위에서 내가 쓴 방법은 확실히 효과가 있으며 문서에 추가하겠습니다. 오늘 밤이나 내일 PR 할게요 :)

업데이트 감사합니다.

당신의 예에서 한 가지 더 깨달았습니다.

'영수증 데이터': 구매[purchases.length - 1].transactionReceipt,
...
const 만료 = 갱신 기록[renewalHistory.length - 1].expires_date_ms

내 테스트에서 구매 및 갱신 기록이 반드시 특정 순서는 아닙니다. 우리가 의도한 것을 사용하고 있는지 확인하기 위해 그것들을 정렬하거나 뭔가를 해야 하지 않을까요?

여기도 마찬가지입니다. 구매 및 갱신 기록은 확실히 주문되지 않으므로 먼저 정렬해야 합니다. dev에서는 많은 반복이 필요합니다.

다음은 Android와 iOS 모두에서 작동하며 최신 영수증 데이터를 얻을 수 있도록 iOS에서 적절하게 정렬하는 기능입니다.

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

@andrewze

Android 시나리오에서 구독이 자동 갱신 가능한 경우 availablePurchases에 반환됩니다.

@curiousdustin @andrewzey 맞습니다. 구매는 주문되지 않습니다. 하지만, RenewalHistory/latest_receipt_info는 항상 저를 위해 주문됩니다. 구매가 주문되지 않았다는 것을 깨달았지만 이것이 실제로 문제가 되지 않는 이유를 찾았다고 생각했습니다. 집에 도착하면 몇 시간 후에 이 문제를 살펴보겠습니다. 나는 우리가 이것을 알아낼 때까지 PR을 제출하고 싶지 않습니다.
편집: 따라서 구매를 정렬할 필요가 없다고 생각하는 이유는 귀하가 쿼리한 구매에 관계없이 expires_date_ms가 동일하게 반환되기 때문입니다. 이것은 여러분도 마찬가지가 아닙니까? 아니면 정렬이 필요한 약간의 정보가 필요합니까? 네 생각을 말해봐. 나는 문서가 구매가 시간순으로 정렬되지 않는다는 점을 여전히 분명히 해야 한다는 데 동의하지만, 내가 말할 수 있는 한 만료 날짜를 얻기 위해 정렬이 필요하지 않습니다.

@kevinEsherick 감사합니다! 제 경우에는 구매 또는 갱신 기록이 주문되지 않았습니다.

@kevinEsherick @andrewzey 이 솔루션에 PR 를 줄 수 있습니까? 고통받는 다른 이들과 나누고자 합니다.

물론 공개 앱 출시가 완료되는 즉시 준비하겠습니다 =).

나는 나의 마지막 코멘트에 관해 더 많은 대화를 기다리고 있었다. 해결되지 않은 몇 가지 문제를 제기했습니다. 참고로 위를 봐주세요. 일단 우리가 그것을 정리하면 우리 중 한 명이 PR을 할 수 있습니다.

@kevinEsherick 아 죄송합니다. 놓쳤습니다.

expires_date_ms 는 각 갱신 영수증에서 확실히 고유합니다. 제가 잘못 이해한 것은 아닐까요? 디코딩된 각 영수증에 첨부된 갱신 영수증 배열은 어떤 영수증이 선택되었는지에 관계없이 동일하므로 필요하지 않은 다음(내 예에서)이 옳을 수 있음을 알 수 있습니다.

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

그러나 나는 정확하려고 노력하고 Apple 문서에서 실제 API 응답의 가능한 불일치를 보완하기 위해 그렇게 했습니다. 자동 갱신 구독에 대해 발생할 가능성이 있는 총 영수증 수를 고려할 때 정렬 작업이 매우 비용이 많이 들 것이라고 생각하지 않습니다.

PR에 ETA가 있습니까? 이 패키지 는 이 경우를 전혀 처리하지 않기 때문에

@schhumannd PR이 문서를 업데이트하는 것일 뿐 react-native-iap 로 이동할 수 있습니다.

최근 출시된 앱에서 내 코드 스니펫이 실제로 문제 없이 작동함을 확인했습니다. https://itunes.apple.com/us/app/rp-diet/id1330041267?ls=1&mt=8

편집 확실히 PR을 하겠지만(Trello의 "Give back to OSS" 목록에 있음), 블랙 프라이데이 주말 광란 이후 😄

@schhumannd 저는 @andrewzey가 말한 두 번째입니다. PR이 말하는 모든 것이 이 게시물에 포함되어 있습니다. 이 문제를 해결하려고 했지만 수행해야 할 작업을 정확히 정리하는 데 시간이 걸렸고 여행과 바쁜 시작 시간이 뒤섞여서 아직 홍보할 시간이 없었습니다. 나는 여전히 곧 할 계획이지만, 원하는 경우 다른 사람이 그 동안 단계를 밟을 수 있습니다. 그리고 @andrewzey 축하합니다 ! 멋져보이네요 다운받겠습니다!

이 스레드가 iOS에서 자동 갱신 구독을 관리하는 올바른 방법을 정확하게 문서화했는지 확신할 수 없지만 대신 이 라이브러리에 의해 노출된 API에 따라 "해결 방법" 워크플로를 설명합니다. 그러나 이것은 전적으로 내 추측이며 내가 틀릴 수 있음을 잘 알고 있으므로 아래에 설명된 관찰에 대한 피드백을 받고 싶습니다.

나는 몇 주 동안 React Native에서 자동 갱신 구독을 관리하는 올바른 방법을 연구했지만 아무 소용이 없었습니다. 그래서 기어를 전환하고 Objective-C/Swift에서 기본적으로 구독을 관리하는 방법을 연구하기 시작했습니다. 이것은 나에게 네이티브 StoreKit API와 문서화된 사용법을 이 라이브러리에 구현된 것과 비교할 수 있는 참조 지점을 제공했습니다.

이 글은 기본 iOS 앱에서 구독 구매, 유효성 검사 및 복원을 처리하는 방법에 대해 지금까지 찾은 최고의 설명입니다. https://www.raywenderlich.com/659-in-app-purchases-auto -renewable-subscriptions-tutorial 및 모든 API가 react-native-iap 에서 사용되는 동안 다른 워크플로를 구현하고 있습니다.

내가 보는 주요 차이점은 appStoreReceiptUrl 입니다.

StoreKit은 내 이해에 따라 iOS 앱에 대한 현재 구매/영수증 정보를 로드하는 올바른 방법인 appStoreReceiptUrl 를 제공합니다. react-native-iap 코드에서 이것이 사용되고 참조되는 것을

이 구현 차이가 문제가 있는지 여부는 확실하지 않지만 react-native-iap API는 결국 getPurchaseHistory 의해 호출되는 StoreKit의 restoreCompletedTransactions 에 불필요한 종속성을 생성하는 것 같습니다 getPurchaseHistory .

react-native-iap API는 iOS에 대해 다음 워크플로를 지원해야 합니다.

• 애플리케이션 시작 시 현재 앱 영수증 로드 시도( appStoreReceiptUrl )
• 영수증을 확인할 수 있는 기회 제공
• appStoreReceiptUrl 가 null인 경우 현재 장치에서 "복원"을 시작한 다음 appStoreReceiptUrl 값을 설정하고 유효성 검사 논리를 다시 시도할 수 있습니다.

생각?

다시 말하지만, 이 라이브러리의 구현 또는 참조된 기본 구현을 오해할 수 있습니다.

@sellmeadog

귀하가 링크한 기사에서도 언급된 요점은 다음과 같습니다.

참고: 프로젝트 앱은 영수증을 수락하고 Apple의 영수증 확인 서비스에 직접 업로드하는 SelfieService를 실행합니다. 이것은 튜토리얼이 구독 설정에 집중하도록 하는 "치트"입니다. 실제 앱에서는 앱이 아닌 원격 서버를 사용해야 합니다.

전체 자동 갱신 구독을 파악하는 데 시간이 걸렸지만 내가 이해하는 가장 좋은 처리 방법은 고유한 백엔드를 단일 소스로 사용하는 것입니다.

• 모든 거래 데이터를 즉시 백엔드로 전송
• 전송 문제의 경우 재전송 수단을 제공합니다(예: 구매 복원).
• 주기적으로(예: 하루에 한 번) 백엔드에 저장된 모든 영수증 확인
• 앱은 예를 들어 백그라운드에서 반환할 때 구독 상태에 대해 백엔드를 쿼리합니다.

나에게 이것은 구독을 처리하는 유일한 제정신인 방법처럼 보였다. 또한 한동안 상업적으로 자동 갱신 구독을 사용하여 다른 개발자와 이 프로세스를 확인했습니다.

따라서 OP 질문에 대한 내 대답은 다음과 같습니다. 프론트엔드가 아닌 백엔드에서 주기적으로 구독을 확인합니다.

@schumand

같은 문제를 이해하거나 이야기하고 있는지 잘 모르겠습니다.

영수증 유효성 검사 는 서버에서 수행해야 합니다. Apple 자체 문서에 따르면 :

앱에서 App Store 서버 /verifyReceipt 엔드포인트를 호출하지 마십시오.

나는 참조된 기사의 "치트"를 백엔드 서버에 위임하는 대신 간결성을 위해 앱에서 직접 /verifyReceipt 대한 샘플 앱의 직접 호출로 해석했습니다.

Apple/App Store는 진실의 단일 출처이며 그래야만 하는 것 같습니다. Apple은 궁극적으로 구매, 갱신, 취소 등을 처리하고 그에 따라 영수증을 생성하고 StoreKit API를 통해 해당 데이터를 사용할 수 있도록 합니다.

react-native-iap 는 문제 없이 구매 및 구매 복원을 처리하지만 여전히 Apple의 문서화된 영수증 액세스 방법인 appStoreReceiptUrl 에서 로컬로 제공되는 App Store 영수증 데이터에 액세스하는 데 격차가 있다고 생각합니다. 데이터 :

영수증 데이터를 검색하려면 NSBundle 의 appStoreReceiptURL 메서드를 사용하여 앱의 영수증을 찾습니다...

Apple 문서를 읽고 기본 Object-C/Swift 구현을 참조하여 이해한 워크플로는 다음과 같습니다.

• 구매할 제품 로드
• 제품 구매(소모, 비소모, 구독, 상관없음)
• 해당 구매에 대한 영수증은 appStoreReceiptUrl 의해 StoreKit appStoreReceiptUrl 에 로컬로 저장됩니다.
• 앱은 필요에 따라 유효성 검사를 위해 영수증 데이터를 백엔드 서버(App Store /verifyReceipt 아닌 직접)로 보내야 합니다.
• appStoreReceiptUrl 는 취소 및/또는 갱신이 발생할 때마다 StoreKit appStoreReceiptUrl 로 업데이트됩니다(적절한 StoreKit 대리인이 올바르게 등록되었다고 가정).
• appStoreReceiptUrl 가 null인 경우 사용자가 새 장치 등을 사용 중이기 때문에 Apple/AppStore에서 현재 영수증 데이터를 검색하고 StoreKit 가 appStoreReceiptUrl 에서 로컬로 유지하는 복원 구매 워크플로를 사용합니다

다시 react-native-iap 는 appStoreReceiptUrl 에서 영수증 데이터를 로드하는 것을 제외하고 이 모든 것을 처리합니다. 현지 영수증을 조회하는 getReceipt 방식을 사용하면 구독 및/또는 기타 구매를 관리하는 부담을 덜 수 있을 것이라고 생각합니다.

애플은 이것을 생각보다 훨씬 더 어렵게 만들었다.

appStoreReceiptUrl 는 취소 및/또는 갱신이 발생할 때마다 StoreKit appStoreReceiptUrl 로 업데이트됩니다(적절한 StoreKit 대리인이 올바르게 등록되었다고 가정).

이것은 내가 이 접근 방식에 대해 가지고 있는 문제를 설명합니다. 사용자가 인터넷 연결이 작동하는 상태에서 이후에 앱을 열지 않으면 갱신/취소/만료 등에 대한 알림을 받지 못합니다.

그 외에는 내가 설명한 접근 방식에 대한 좋은 대안인 것 같습니다. 어떤 것이 프로덕션 앱에 가장 많이 사용되는지 궁금합니다.

@sellmeadog 나는 그것이 내가 여기에 게시한 것과 같은 생각이라고 생각합니다: #356
현지에서 영수증을 확인하는 것도 한 가지 방법이라고 Apple은 권장합니다. 이는 모든 서버/네트워크 요청과 완전히 독립적입니다.

네. "네트워크 연결 없음 - 유효성 검사 없음"과 관련된 단점이 있습니다.
그러나 이에 대한 사용 사례가 있습니다.
모든 앱을 실행할 때마다 영수증을 빠르게 확인하고 UserDefaults 또는 Keychain 를 통해 인앱 구매를 추적하고 싶지 않습니다. StoreKit 이미 저장 메커니즘을 제공합니다.

IOS 사용자가 getAvailablePurchases와 같은 것을 통해 itunes 계정에 로그인하라는 메시지를 표시하지 않고 구독을 갱신하거나 취소했는지 어떻게 확인해야 합니까?

예를 들어:
구독을 처음 구매할 때 영수증을 확인하고 만료 날짜를 Firebase 프로필에 저장합니다. 해당 Firebase 노드를 사용하여 활성화된 구독이 있는지 시작 시 확인합니다. 문제는 만료일이 지나고 새로운 청구 기간이 시작될 때 발생합니다. 자동 갱신 또는 취소되었는지 어떻게 확인할 수 있습니까? 언급했듯이 우리는 getAvailablePurchases를 사용하고 있었지만 복원 버튼처럼 itunes 로그인을 프롬프트합니다. 이것은 끔찍한 UI입니다.

저도 같은게 궁금합니다.

앱에서는 상태를 확인하기 위해 Apple과 직접 통신하는 서버 측 API가 있으므로 이 항목이 필요하지 않습니다. 최초 구매 후 영수증 데이터는 당사 서버에 저장되고 나중에 업데이트된 상태를 요청하는 데 사용됩니다.

그러나 나는 이것이 장치 측면에서 여전히 가능해야 한다고 생각합니다. 나는 이에 대한 전문가는 아니지만 내가 이해하는 바에 따르면 앱은 갱신이 발생할 때마다 OS에서 업데이트된 거래/영수증을 받습니다. 이 플러그인이 앱 실행 시 이러한 영수증을 처리하는 것 같습니다. (Xcode에서 실행할 때 여러 트랜잭션을 처리하는 것으로 보이는 많은 로그를 봅니다.) 하지만 제가 알 수 있는 바에 따르면 JS 코드에서 이러한 이벤트를 활용할 방법이 없습니다.

이것에 대해 더 많은 정보를 얻을 수 있습니까?

@csumrell @curiousdustin 프로덕션 환경에서 이 동작이 확인되었습니까? 장치에 샌드박스가 아닌 다른 계정이 있을 수 있으므로 샌드박스 계정에 로그인해야 하는 샌드박스 때문에 발생할 수 있는지 궁금합니다. 반면 프로덕션에서는 사용자가 일반 계정으로 로그인하고 이 모듈은 로그인을 요구하지 않고 getPurchases를 사용할 수 있습니다.

죄송합니다. getAvailablePurchases() 가 프로덕션에서 암호 프롬프트를 유발하는지 확인하지 않았습니다.

문서에서 일반적으로 구매 복원이라고 하는 기능에 사용되는 이 방법에 대해 이야기하기 때문에 그럴 것이라고 가정했습니다. 내 경험에 따르면 이 방법은 적어도 iOS에서 인증을 포함합니다.

@hyochan @JJMoon 이것도 좀 더

@curiousdustin 예 , 일반 iTunes 계정에서 로그아웃하고 샌드박스 계정으로 로그인하면 이 메서드가 호출될 때 더 이상 로그인하라는 메시지가 표시되지 않습니다. 따라서 내 추측/희망은 사용자가 사용 중인 샌드박스 계정이 없는 프로덕션 환경에서 문제가 발생하지 않아야 한다는 것입니다. 베타 테스트는 사용자가 장치에 샌드박스 계정을 설정하지 않은 경우 프로덕션과 동일한 방식으로 작동해야 합니다. 이는 개발 장치의 문제일 뿐입니다. 그래서 내일 베타 사용자와 함께 이것을 테스트하고 내가 찾은 것을 알려 드리겠습니다.
편집: 샌드박스가 아닌 장치에서 이러한 일이 발생함을 확인할 수 있습니다. 이것은 끔찍한 UX이며 상당히 문제가 있습니다. 누구, 어떤 아이디어라도?

따라서 앱에서 App Store 서버 /verifyReceipt 엔드포인트를 호출하여 자체 서버에서 유효성을 검사할 때 원래의 첫 번째 구매 영수증과 함께 해당 사용자에 대한 최신 업데이트 정보를 항상 반환합니다.

로컬 유효성 검사 방법을 사용하면 항상 최신 정보도 반환되는지 아는 사람이 있습니까? 아니면 해당 영수증에 대해서만 로컬에서 확인하는 것입니까?

또한 Apple과 함께 유효성을 검사하기 위해 자체 서버를 설정하는 방법에 대한 조언이 있는 사람이 있습니까? 나는 그것에 대한 경험이 없다

@csumrell getPurchaseHistory를 호출하고 정렬하여 최근 구매에 대한 영수증을 얻을 수 있습니다. 위의 주석은 이 작업을 수행하는 방법을 자세히 설명합니다. 여기에는 최신 정보가 있어야 합니다.

그리고 서로를 도울 수 있도록 서버에서 유효성을 검사하는 옵션을 탐색하려고 합니다. 다른 사람이 그것에 대해 어떻게 갔는지 듣고 싶습니다.

@kevinEsherick 예, 하지만 getPurchaseHistory는 Itunes 로그인 팝업을 트리거합니다. 사용자가 처음 구매할 때 원본 영수증을 로컬 저장소에 저장하는 것에 대해 이야기하고 있습니다. 그런 다음 getPurchaseHistory를 호출하여 다음 청구를 확인하는 대신 로컬에서 검증된 validateReceiptIos(originalReceipt)를 호출합니다. 그러나 validateReceiptIos가 Apple 서버 /verifyReceipt와 같은 최신 트랜잭션을 반환하는지 확실하지 않습니다.

@csumrell 갓챠 . 빠르고 쉽게 테스트할 수 있습니다. 안써봤어? 아니라면 오늘 늦게 확인하겠습니다.
편집: @csumrell validateReceiptIos는 실제로 해당 구매에 대한 최신 자동 갱신을 추적하므로 이것이 유효한 방법입니다. 나는 이것이 iTunes 로그인 프롬프트를 피하기 때문에 구독을 확인하기 위해 위에서 제안한 방법보다 낫다고 말하고 싶습니다. 단점은 영수증을 로컬에 저장해야 한다는 것입니다. 이것은 너무 번거롭지 않아야 합니다. 또한 보안상의 이유로 또는 대용량(최대 60,000자)이라는 사실 때문에 이러한 영수증이 백엔드로 가는 것을 원하지 않을 수 있습니다. 따라서 구독한 사용자가 로그아웃하거나 새 장치를 사용하기 시작하면 다음을 수행해야 합니다. 최신 구매 영수증을 받으려면 로그인하라는 메시지가 표시됩니다. 마지막으로 확인한 사용자에게만 메시지를 표시하도록 구독 상태를 내부적으로 저장할 수 있습니다.

@hyochan 은 이 문제에 $20.00를 기부했습니다. IssueHunt에서 확인하세요.

@hyochan 구체적으로 어떤 솔루션에 자금을 지원하고 있습니까? 우리는 이 스레드에서 몇 가지를 제공했으며 내 최근 의견이 가장 적은 문제로 가장 강력한 솔루션을 제공한다고 생각합니다. README에 대한 하나의 간결한 PR로 이러한 솔루션을 수집하기 위해 누군가에게 자금을 지원하고 있습니까? 아니면 여전히 해결되기를 원하는 실제 코드 문제가 있습니까?

@kevinEsherick

README에 대한 하나의 간결한 PR로 이러한 솔루션을 수집하기 위해 누군가에게 자금을 지원하고 있습니까?

예. 이것은 절대적으로 맞습니다. 또한 issue hunt 가 기본적으로 어떻게 작동하는지 테스트하고 싶었습니다. 내 다음 계획은 테스트 케이스를 만드는 데 자금을 조달하는 것입니다.

@kevinEsherick 맞습니다. validateReceiptIos를 사용한 로컬 유효성 검사는 실제로 원래의 첫 번째 트랜잭션 ID(redux 상태에 저장됨)만을 사용하여 구독에 대한 최신 정보를 반환합니다.

나는 이 방법을 사용하여 내 서버를 설정할 필요가 없고 구독이 활성화되어 있는지 확인하는 동안 iTunes 로그인 팝업이 표시되지 않도록 할 것입니다.

@csumrell 과 내가 배치한 이 유효성 검사 흐름 사용을 고려하는 사람들을 위한 참고 사항: 개발 중인 iTunes 로그인 프롬프트가 처음 시작할 때 여전히 팝업되는 것으로 나타났습니다. 이것은 프로덕션에서 발생하지 않습니다. 우리가 제시한 단계를 따르기만 하면 모두 괜찮을 것입니다. 이 작업을 수행하는 이유에 관해서는 아마도 iOS가 IAP가 사용 중이거나 개발 중인 모듈 맵의 일부임을 확인하면 자동으로 로그인하라는 메시지를 표시합니다. 확실하지 않지만 샌드박스 테스트의 기능인 것 같습니다.

안녕하세요, 최근에 이 문제에 대한 활동이 없는 것 같습니다. 문제가 해결되었습니까? 아니면 여전히 커뮤니티의 관심이 필요한가요? 더 이상 활동이 발생하지 않으면 이 문제가 종료될 수 있습니다. 또한 이 문제에 "토론용" 또는 "좋은 첫 번째 문제"라는 레이블을 붙일 수 있습니다. 그러면 열어 두겠습니다. 귀하의 기여에 감사드립니다.

장기간 사용하지 않으면 이 문제를 종료합니다. 이 문제가 최신 릴리스에 여전히 존재하는 경우 언제든지 최신 정보로 새 문제를 생성하십시오.

아마도 이 전체 흐름을 문서에서 명확히 해야 합니까?

특히 자동 갱신 구독의 경우? expires_date_ms 구독이 아직 활성화되어 있는지 여부를 확인할 수 있는지 여부는 신규 이민자에게 매우 불분명합니다.

나는 이것을 위한 가장 좋은 장소가 보다 완전한 작업 예제일 것이라고 제안합니다.

사람들이 이것에 관심을 가질까요? 시간이 된다면 이 작업을 해도 될까요?

@alexpchin 네, 확실히 개발 시간이 많이 절약되고 업장이 깨끗해집니다:D

동의하다! #856에 관심이 있는 사람이 있습니까?

안녕,

@andrewzey 의 방법은 어제 갑자기 더 이상 구독에 대한 영수증의 유효성을 검사하지 않게 될 때까지 훌륭하게 작동했습니다. validateReceiptIos()를 호출할 때 iOS에서 JSON 구문 분석 오류가 다시 발생합니다. 나는 이것을 다른 사람이 만난 적이 없다고 생각합니다 ...? 어제 이후 변경된 유일한 변경 사항은 변수를 제거하는 데 도움이 되도록 제거한 ITC에 프로모션 코드가 추가된 것입니다. 영수증이 JSON 구문 분석에 실패해야 하는 이유가 있습니까? sortedAvailablePurchases의 인덱스 0에 있는 영수증뿐만 아니라 반환된 모든 영수증에 대해 실패합니다. 코드는 기본적으로 andrewzey의 예와 동일합니다. 오류가 발생했기 때문에 validateReceiptIos 이후에 모든 것을 생략했습니다.

RN 0.61.4, RNIap: 4.4.2 및 iOS 13.3.1을 실행 중입니다.

우리는 시도했습니다:

• 앱 재설치
• 새 사용자 계정
• 새 앱 암호 사용
• 각 사용자의 모든 영수증 테스트 - 단 하나의 영수증도 구문 분석할 수 없습니다.

샌드박스 구매를 할 때 finishTransactionIOS를 올바르게 사용하지 않았는지 궁금합니다.

정말 이상한 점은 이 온라인 도구를 사용하여 영수증의 유효성을 검사할 때 모든 것이 정상적으로 보이고 모든 영수증 메타데이터를 볼 수 있다는 것입니다.

  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
      }
...

@andrewzey가 배치한 코드에 관한 질문입니다. Date.now() 가 현재 장치 시간이 아니고 사용자가 이를 변경하고 무제한 구독을 가질 수 있습니까? 🤔

또한 앱 자체에서 영수증을 확인하는 것이 좋지 않습니까?

@doteric 그들이 낙담했다고 언급한 곳을 알려 주시겠습니까? 서버 측 알림을 설정할 수 있다는 것을 알고 있지만 제 관점에서는 서버 대신 클라이언트에서 이 유효성 검사를 처리하는 것이 훨씬 쉬워 보입니다.
Apple 또는 기타 견고한 반응 네이티브 소스에서 올바른 문서를 찾기 위해 고군분투하고 있습니다.

@doteric yes Date.now()는 장치 시간이므로 해결할 수 있습니다. 그러나 사용자가 이 작업을 수행할 가능성은 희박하며 다른 방법을 사용해도 끝없는 구독이 가능합니다. 예를 들어 간단한 서버 측 유효성 검사를 사용하는 경우 앱을 열기 전에 비행기 모드로 전환하여 앱이 구독이 만료되었음을 인식하지 못하도록 할 수 있습니다. 물론 배치할 수 있는 다른 보호 기능이 있지만 제 요점은 Date.now()를 사용하는 클라이언트 측이 확실히 작동한다는 것입니다. @captaincole 나는 문서를 가지고 있지 않지만 클라이언트 측 유효성 검사가 권장되지 않는다는 것을 읽었음을 확인할 수 있습니다. 나는 그것을 내가 믿는 Apple 문서에서 읽었습니다. 즉, 클라이언트 측에서 작업을 완료한다고 생각합니다.

@kevinEsherick @captaincole

iOS의 클라이언트 측 영수증 확인 정보:

• https://developer.apple.com/documentation/storekit/in-app_purchase/validating_receipts_with_the_app_store#//apple_ref/doc/uid/TP40010573 -CH104-SW3
• https://developer.apple.com/documentation/storekit/in-app_purchase/choosing_a_receipt_validation_technique#//apple_ref/doc/uid/TP40010573 -CH105-SW1

안녕,

validateReceiptIos 및 latest_receipt_data(expires_date_ms를 실제 날짜와 비교)를 사용하여 이 스레드에서 논의된 접근 방식 중 하나를 시도했습니다. Xcode에서 개발하는 동안 훌륭하게 작동했습니다. 그러나 Testflight에서 테스트했을 때 더 이상 작동하지 않았습니다. 디버깅이 어렵기 때문에 정확한 문제를 식별할 수 없으며 영수증 데이터를 얻지 못하는 것 같습니다. 누구든지 testflight와 비슷한 문제가 있습니까?

미리 감사드립니다!

안녕,

validateReceiptIos 및 latest_receipt_data(expires_date_ms를 실제 날짜와 비교)를 사용하여 이 스레드에서 논의된 접근 방식 중 하나를 시도했습니다. Xcode에서 개발하는 동안 훌륭하게 작동했습니다. 그러나 Testflight에서 테스트했을 때 더 이상 작동하지 않았습니다. 디버깅이 어렵기 때문에 정확한 문제를 식별할 수 없으며 영수증 데이터를 얻지 못하는 것 같습니다. 누구든지 testflight와 비슷한 문제가 있습니까?

미리 감사드립니다!

+1

@asobralr @Somnus007 제가 틀릴 수도 있지만 사용자가 testflight를 통해 구매할 수 없기 때문에 testflight로 IAP를 테스트할 수 없다고 생각합니다. Apple은 프로덕션과 유사한 환경에서 구매를 테스트할 수 있는 좋은 기회를 제공하지 않습니다.

@asobralr @Somnus007 제가 틀릴 수도 있지만 사용자가 testflight를 통해 구매할 수 없기 때문에 testflight로 IAP를 테스트할 수 없다고 생각합니다. Apple은 프로덕션과 유사한 환경에서 구매를 테스트할 수 있는 좋은 기회를 제공하지 않습니다.

옳은. 샌드박스에서 실패 시나리오를 시뮬레이션할 수도 없습니다. 이는 부끄러운 일입니다. 😞

안녕하세요 @kevinEsherick님 , 답변 감사합니다. 당신이 틀릴 수 있습니다. 사용자는 teslflight를 통해 구매할 수 있습니다. testflight에서 사용자는 실제 사과 계정과 동일한 이메일 주소를 가진 샌드박스 계정에 로그인해야 하는 것 같습니다. 그러면 모든 것이 잘 작동합니다. BTW, getPurchaseHistory 가 프로덕션 환경에서 iTunes 로그인 팝업을 트리거합니까?

ios 14는 requestSubscription()을 호출하기 전에 getAvailablePurchases()를 호출할 때 문제가 있다는 사실 때문에 이 솔루션을 중단한 것 같습니다.