2015-12-03 3 views
15

में रसीद सत्यापन और रसीद ताज़ा करना समझना हमारे पास आईओएस में रसीद सत्यापन प्रवाह को पूरी तरह से समझने में समस्याएं हैं।आईओएस

applicationDidFinishLaunching में और applicationWillEnterForeground में हम सर्वर साइड पर रसीद मान्य, अगर वहाँ कोई रसीद है या रसीद अमान्य है, हम रसीद ताज़ा करने का प्रयास:

यहाँ हम वर्तमान में (विकास) करना है और इसे पुन: सत्यापित करें।

  1. क्या ऐसे मामलों में जहां कोई रसीद डिवाइस पर उपलब्ध है कर रहे हैं:

    यहां कुछ समस्याएं/सवाल कर रहे हैं?

  2. क्या हमें कोई रसीद मिलने पर हमेशा रसीद ताज़ा अनुरोध जारी करना चाहिए?

  3. कभी-कभी स्टार्टअप पर यह अलर्ट बॉक्स क्यों दिखाया जाता है? मैं समझता हूं कि यह रसीद ताज़ा अनुरोध पर दिखाया गया है?

Sign in required?

  1. जब एक रसीद सत्यापन उसका क्या होगा? जब भी खरीद को सत्यापित करने के लिए खरीदारी की जाती है, तो हम वर्तमान में ऐसा करते हैं, क्या यह सही उपयोग है?

उत्तर

8
  1. उत्पादन में एक रसीद हमेशा डिवाइस पर उपलब्ध है। के बाद परीक्षण में पहले इंस्टॉल नहीं है। तो यदि आप एक सही परीक्षण करना चाहते हैं, आपको खरीद को पुनर्स्थापित करना होगा भले ही वह उस उपयोगकर्ता पर पर्यावरण में खरीदारी मौजूद न हो। ऐसा क्यों है? ऐपस्टोर से डाउनलोड की गई ऐप हमेशा रसीद के साथ आता है भले ही वे स्वतंत्र हों।
  2. उस व्यवसाय तर्क पर निर्भर करता है जिसे आप लागू करना चाहते हैं। यदि आप प्रत्येक बार जब ऐप लॉन्च करते हैं तो सर्वर के खिलाफ रसीद को मान्य कर रहे हैं, बेशक आपको रसीद की आवश्यकता है। यदि यह मौजूद नहीं है (लेकिन उत्पादन में हमेशा होता है) या मान्य नहीं है, तो आप रीफ्रेश या पुनर्स्थापित करने के लिए कह सकते हैं, लेकिन जहां तक ​​मुझे याद है कि आपको हमेशा उपयोगकर्ता से पहले पूछना चाहिए कि वह ऐसा करना चाहता है (वह हो सकता है अस्वीकार करने का कारण)। पुनर्स्थापित करें और रीफ्रेश एक ही चीज़ नहीं हैं।
  3. यह आमतौर पर खरीद/पुनर्स्थापना/रीफ्रेश में दिखाई देता है। लेकिन अगर खाते में कुछ लंबित अनुरोध हैं क्योंकि ऐप क्रैश हो गया है या किसी भी तरह से अनुरोध समाप्त होने से पहले आपने डिबगिंग में बाधा डाली है, तो आप इससे बहुत ऊब जाएंगे। प्रोग्रामेटिक रूप से उन्हें फ्लश करने का कोई तरीका नहीं है, बस तब तक लॉग इन करें जब तक वे रुक जाएं। बेशक यह एक वैध परीक्षण नहीं होगा।
  4. यह आपके ऊपर और खरीदारी की तरह है। यदि यह एक ऑटोरेनेबल सदस्यता है, तो आप एक सर्वर के खिलाफ रसीद को मान्य कर सकते हैं, फिर ग्राहक पर "समाप्ति तिथि" स्टोर कर सकते हैं और दिनांक समाप्त होने के बाद एक और जांच कर सकते हैं। ध्यान दें कि प्राप्तियां काफी बड़ी हो सकती हैं, क्योंकि सभी इतिहास मूल्य भी हैं।
+1

मुझे लगता है कि यह एक सुंदर ठोस जवाब है, धन्यवाद। इसलिए, अगर हम स्टार्टअप पर रसीद को सत्यापित करने के लिए सख्त नहीं हैं, तो क्या प्रत्येक खरीद के बाद यह करने के लिए एक अच्छा मुद्दा होगा? हम भी बिंदु 2 में भागना नहीं चाहते हैं।) आपने उल्लेख किया है। तो प्रवाह होगा: 1) उपयोगकर्ता खरीद सदस्यता। 2) रसीद सत्यापित करें 3) Verificaion सफल: समाप्ति तिथि के लिए एक स्थानीय अधिसूचना अनुसूची (क्या यह एक सुरक्षित विधि है?)। 4) रसीद की समाप्ति अधिसूचना निकाल दी गई -> प्रीमियम सुविधाओं को पुन: सत्यापित या लॉक करें। क्या यह इसे संभालने का एक अच्छा तरीका प्रतीत होता है? –

+1

मैं वास्तव में खरीद की तरह पर निर्भर करता हूं। अगर सदस्यता नहीं है तो खरीदारी के ठीक बाद एक वैधता मेरे लिए ठीक है। यदि यह एक सदस्यता है तो आपको इसके अंत को जानना चाहिए, इस प्रकार स्थानीय अधिसूचना को छोड़कर आपने अपना प्रवाह प्रस्तुत किया है। आइए मान लीजिए कि आप मासिक ऑटो नवीकरणीय सदस्यता खरीद रहे हैं, प्रत्येक महीने यदि उपयोगकर्ता ऑटो नवीनीकरण तंत्र को नहीं रोकता है, तो सदस्यता स्वचालित रूप से नवीनीकृत हो जाती है। मैंने यह समझने की कोशिश की है कि यह सफलता के बिना कब होता है, संभवतः वास्तविक समाप्ति तिथि से कुछ दिन पहले। – Andrea

+0

स्वचालित रूप से इसका मतलब है कि आपको कुछ भी करने की आवश्यकता नहीं है। मैं समय-समय पर (कीचेन) को समय-समय पर सहेज लेगा, जब मैं उस तारीख के आसपास हूं, तो मैं रसीद को फिर से सत्यापन के लिए भेज दूंगा, जब तक कि उसकी समयसीमा समाप्त हो या अपडेट न हो जाए। यदि प्रमाणीकरण एक नया महीना देखता है तो मैं तिथि अपडेट करता हूं, अगर रसीद की समयसीमा समाप्त हो जाती है तो मैं एक चेतावनी पेश करूंगा जैसे "आपकी सदस्यता समाप्त होने की उम्मीद है $ $ की तारीख $ क्या आप रीफ्रेश करने का प्रयास करना चाहते हैं"? आप उपयोगकर्ता को पूछे बिना हर बार अपने सत्यापन सर्वर को रसीद भेज सकते हैं, लेकिन आप उपयोगकर्ता से पूछे बिना रीफ्रेश या पुनर्स्थापित नहीं कर सकते हैं। – Andrea

0

1. कोई खरीद/पुनर्स्थापित नहीं हुआ।
2. नहीं। 1
4. सुरक्षित। उपभोग योग्य उत्पादों के लिए, रीप्ले हमले को हराने के लिए, अपने सर्वर पर हैश को सहेजना याद रखें।

+0

मुझे वास्तव में यहां समझ में नहीं आता है। सत्यापन रसीद यह जांचना है कि यह वैध लेनदेन है या नहीं, है ना? तो लेनदेन की स्थिति के बाद 'खरीदा गया' है, मैं ऑर्डर सत्यापित करने के लिए रसीद को मान्य करने के लिए कहता हूं। और यदि रसीद अमान्य है, तो चिह्नित करें कि ट्रांज़ेक्शन धोखाधड़ी है, है ना? – TomSawyer

+0

@ टॉमसायर यप। –

2
  1. झांग उल्लेख किया है, अगर कोई खरीद है या पुनर्स्थापना जगह ले ली है, वहाँ की दुकान
  2. रसीद का पता करने में कोई रसीद किया जाएगा। अगर कोई रसीद नहीं मिलती है, तो सत्यापन विफल हो जाता है और आपको रसीद फिर से ताज़ा करने का अनुरोध नहीं करना चाहिए। केवल तभी जब आप स्वयं प्रक्रिया को पुनर्स्थापित करेंगे, आपको फिर से रसीद के लिए अनुरोध करना चाहिए।
  3. यह हमेशा दिखाया जाएगा जब आप रसीद को रीफ्रेश करने का प्रयास करेंगे (या आप उन सेटिंग्स से चुनेंगे जिन्हें आप 15 मिनट के लिए पासवर्ड नहीं मांगना चाहते हैं)।
  4. हां।

अधिक जानकारी के लिए यहाँ देखें: https://www.objc.io/issues/17-security/receipt-validation/#about-validation