Launch खरीद अवधि और खाता SDK की सीमाएँ

यह बदलाव केवल स्थानीय रूप से विकसित और सत्यापित हुआ है; Launch डिप्लॉय नहीं हुआ और SDK पैकेज प्रकाशित नहीं हुआ। वर्तमान स्रोत Licentivo के खाता प्राधिकरण प्रोटोकॉल और संबंधित आधिकारिक SDK अपडेट पर निर्भर है; इसे केवल दीर्घकालिक लाइसेंस कुंजी समर्थित पुराने सर्वर के साथ नहीं मिलाया जा सकता।

ज़िम्मेदारियाँ

Launch के ऑर्डर, खरीद अवधि और सिंक्रनाइज़ेशन पूर्ण चिह्न संरक्षित सुविधाओं को अनुमति नहीं दे सकते। क्लाइंट को संरक्षित कार्य आधिकारिक SDK के RunFeature जैसे रनटाइम इंटरफ़ेस से करने चाहिए।

प्रत्येक Launch उत्पाद एक स्थिर सार्वजनिक Licentivo उत्पाद रूट सहेजता है। एक उत्पाद के प्लान अलग नीतियाँ चुन सकते हैं, पर दूसरे दूरस्थ उत्पाद पर नहीं जा सकते; मैपिंग सहेजना साझा उत्पाद की डेटाबेस पंक्ति लॉक से क्रमबद्ध सत्यापित होता है। ग्राहक पहचान, प्लान प्रकाशन और SDK एकीकरण कॉन्फ़िगरेशन एक ही बाइंडिंग पढ़ते हैं; ड्राफ़्ट पहले खरीद चुके ग्राहकों का उत्पाद संदर्भ नहीं बदल सकता। यह केवल एकीकरण कॉन्फ़िगरेशन की संगति जाँचता है, सुविधा या डिवाइस प्राधिकरण तय नहीं करता। पुराने डेटाबेस में स्थिर फ़ील्ड न होने पर पहले खरीद और प्रकाशन इतिहास देखें; अद्वितीय पुष्टि संभव न होने पर PRODUCT_MAPPING_CONFLICT लौटता है। विवरण मैपिंग समवर्ती सुधार में है।

खरीद अवधि सिंक्रनाइज़ेशन

मौजूदा इंटरफ़ेस दोबारा उपयोग करें, नए भुगतान तथ्य, रिफ़ंड तथ्य या कोट सेवा न जोड़ें:

• POST /api/v1/launch/connections、PUT /connections/{id}: पहचान हस्ताक्षर सार्वजनिक कुंजियाँ पंजीकृत करें, उत्पादन और परीक्षण वातावरण के लिए अलग कनेक्शन बनाएँ।
• PUT /api/v1/launch/connections/{id}/plans/{plan}: अद्वितीय Launch प्लान संस्करण संदर्भ और दूरस्थ उत्पाद, नीति संस्करण पंजीकृत करें।
• POST /api/v1/launch/connections/{id}/events: पूरा संस्करणित खरीद स्नैपशॉट जमा करें।
• GET /api/v1/launch/connections/{id}/events/{event}: प्रसंस्करण परिणाम की पुष्टि करें।
• POST /api/v1/launch/connections/{id}/events/{event}/retry: जाँच के बाद मूल इवेंट दोबारा आज़माएँ।

स्नैपशॉट में केवल इवेंट नंबर, वातावरण, इवेंट प्रकार, खरीद संदर्भ, अनाम खाता संदर्भ, Launch उत्पाद, प्लान संस्करण संदर्भ, बढ़ता संस्करण और निरपेक्ष valid_from / valid_until होते हैं; माइग्रेशन में पुराना लाइसेंस ID भी होता है। भुगतान कुंजी, कीमत, ग्राहक ईमेल या दीर्घकालिक लाइसेंस कुंजी नहीं भेजी जाती। स्थायी खरीद में valid_until का मान null है; Licentivo नीति से मिलान सत्यापित करता है।

Launch एक ही डेटाबेस लेनदेन में भुगतान की पुष्टि, अपरिवर्तनीय खरीद कवरेज अंतराल का रिकॉर्ड और सिंक्रनाइज़ेशन कार्य सहेजता है। दिन/माह/वर्ष के कैलेंडर चक्र से समय सीमा गणना होती है; नवीनीकरण मूल खरीद एंकर रखता है, समाप्ति के बाद भुगतान होने पर वास्तविक भुगतान समय से शुरू होता है। अपग्रेड कोट और अवधि अब भी Launch में गणना होते हैं।

हर बदलाव पर पूरे निरपेक्ष मान भेजें, पुनः प्रयास में वही इवेंट ID और निकाय उपयोग करें, “और N दिन जोड़ें” न भेजें। कार्य अनुरोध, दूरस्थ कनेक्शन और प्रगति स्थायी रूप से सहेजता है; प्रतिक्रिया खोने, प्रक्रिया पुनरारंभ और समवर्ती वर्कर से अवधि दोबारा नहीं जुड़ती।

HTTP 202 केवल Licentivo द्वारा प्राप्ति दर्शाता है। केवल applied मिलने पर सिंक्रनाइज़ेशन पूर्ण चिह्नित करें; pending पर पूछते रहें, manual_review और अपुष्ट stale जाँच की प्रतीक्षा में रखें। नेटवर्क त्रुटि पर बैकऑफ़ पुनः प्रयास करें, लगातार विफलता सीमा पर मैनुअल जाँच में जाएँ।

रिफ़ंड केवल संबंधित ऑर्डर का कवरेज अंतराल हटाता है: अपग्रेड ऑर्डर का रिफ़ंड मूल प्लान बहाल करता है; नवीनीकरण ऑर्डर का रिफ़ंड संबंधित विस्तार हटाता है; अन्य गैर-रिफ़ंड खरीद रहने पर पुनर्गणित परिणाम सिंक्रनाइज़ करें, सब खरीद निरस्त न करें। सभी खरीद रिफ़ंड होने पर entitlement.refunded भेजें। बाद की पुनः खरीद में नया खरीद संदर्भ उपयोग करें, ताकि निरस्त दूरस्थ लाइसेंस पुनर्जीवित न हो।

चैनल द्वारा पुष्ट हारी चार्जबैक या भुगतान वापसी भी केवल संबंधित ऑर्डर का खरीद कवरेज हटाती है; ऑर्डर reversed दिखता है और वास्तविक प्राधिकरण बदलाव Licentivo द्वारा खरीद स्नैपशॉट लागू करने के बाद संसाधित होता है। लंबित विवाद खरीद रिकॉर्ड नहीं बदलता। जाँच प्रतीक्षित पुराने वापसी नोटिस मूल चैनल से पुनः हस्ताक्षर सत्यापित कर दोबारा भेजकर बहाल किए जा सकते हैं।

अज्ञात रिफ़ंड मैनुअल समीक्षा में जाने के बाद व्यवस्थापक POST /api/v1/admin/refunds/{id}/reconcile से मूल कार्रवाई बहाल कर सकता है। रसीद मूल लेनदेन, मुद्रा और राशि से मेल खानी चाहिए; मूल कार्रवाई नंबर और स्वीकृति समय नहीं बदलने चाहिए, सुरक्षित पुनः प्रयास अवधि के बाद धन अनुरोध बिना जाँच दोबारा जमा न करें।

खाता और क्लाइंट

1. क्लाइंट वास्तविक डेस्कटॉप लॉगिन सत्र बनाने के लिए POST /api/v1/auth/login उपयोग करता है।
2. Launch SDK POST /api/v1/software/products/{id}/identity अनुरोध करता है और sandbox या live निर्दिष्ट करता है।
3. Launch अधिकतम 120 सेकंड का पहचान assertion जारी करता है, जिसमें निर्दिष्ट प्राप्तकर्ता और उत्पाद/खरीद संदर्भ, वास्तविक लॉगिन sid और लॉगिन समाप्ति होती है। assertion में सुविधाएँ, डिवाइस कोटा या ऑफ़लाइन अधिकार नहीं होते।
4. Launch SDK केवल मेमोरी में identity_token, launch_connection_id, environment आधिकारिक SDK को देता है, license_key खाली है।
5. आधिकारिक SDK Licentivo /api/v1/launch/exchange कॉल करता है; Licentivo प्राधिकरण तय करता है और डिवाइस क्रेडेंशियल तथा हस्ताक्षरित अनुमति जारी करता है।

Launch का सामान्य खाता रिकॉर्ड v2 उपयोग करता है, केवल खाता सत्र और सार्वजनिक रूट जानकारी सहेजता है, assertion, लाइसेंस कुंजी या प्राधिकरण अनुमति नहीं। स्पष्ट लॉगआउट पर यह केवल निरस्तीकरण के लिए निजी v3 लंबित कार्य बनता है, जिससे लॉगिन बहाल नहीं हो सकता; Launch सत्र निरस्तीकरण की पुष्टि के बाद ही हटाएँ। पुराना /credential इंटरफ़ेस HTTP 410 लौटाता है। सार्वजनिक कुंजी और उत्पाद ID ऐप के साथ वितरित हो सकते हैं, प्रबंधन कुंजी केवल सर्वर पर रहती है।

लॉगआउट, बंद करना, दूरस्थ अनलिंक

आधिकारिक SDK का लॉगआउट इस प्रक्रिया में प्राधिकरण उपयोग तुरंत रोकता है, रनटाइम क्रेडेंशियल साफ़ करता है और समर्पित लॉगआउट टिकट से दूरस्थ बाइंडिंग निरस्त करता है। नेटवर्क विफलता पर SDK की .logout.json रखनी आवश्यक है; परिणाम में दूरस्थ निरस्तीकरण लंबित दिखना चाहिए, अनलिंक सफल नहीं। Launch SDK आधिकारिक SDK की कैश निर्देशिका न हटाता, न उसमें घूमकर सफ़ाई करता, न बदलता है; लंबित निरस्तीकरण टिकट संबंधित कैश फिर आरंभ होने पर आधिकारिक SDK बहाल कर संसाधित करता है।

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

दूरस्थ अनलिंक अनुरोध में मूल सूची से मिले activation_id और expected_generation होते हैं, पुनः प्रयास वही operation_id उपयोग करता है। Launch अनलिंक संख्या नहीं गिनता, अनलिंक कतार स्वयं स्वीकृत या निष्पादित नहीं करता और पीढ़ी रीफ़्रेश कर पुरानी कार्रवाई स्वतः नहीं दोहराता। शेष संख्या, रिलीज़ अनुमति, समीक्षा और अंतिम परिणाम सभी Licentivo से आते हैं।

खाता बहाली Restore के लिए ऑनलाइन खाता पुष्टि और नया पहचान assertion आवश्यक है; खाता सेवा विफल होने पर Launch स्वयं ऑफ़लाइन अनुमति नहीं चुनता। ऑफ़लाइन शुरू होने वाले ऐप आधिकारिक SDK के बहाली अनुबंध से जुड़ते हैं; हस्ताक्षर, ऑफ़लाइन अवधि और घड़ी जाँच अब भी आधिकारिक SDK करता है।

सर्वर-साइड पहचान निरस्तीकरण

Licentivo V39 के मौजूदा इंटरफ़ेस से जुड़ें, वाणिज्यिक तथ्य या कोट इंटरफ़ेस आवश्यक नहीं:

• POST /api/v1/launch/connections/{id}/session-revocations: निर्दिष्ट sid या खाते के पुराने लॉगिन निरस्त करें, सिंक्रोनस प्रतिबद्ध रसीद लौटाएँ।
• GET /api/v1/launch/connections/{id}/session-revocations/{event_id}: मूल इवेंट का प्रतिबद्ध परिणाम प्राप्त करें, खोई प्रतिक्रिया वाला अनुरोध बहाल करें।

सामान्य डेस्कटॉप लॉगआउट और निर्दिष्ट सत्र का बलपूर्वक लॉगआउट scope=session उपयोग करते हैं; पासवर्ड बदलने, रीसेट, ईमेल बदलाव, खाता अक्षम करने और वेबसाइट कर्मियों की भूमिका बदलने से सभी सत्र अमान्य होने पर scope=account उपयोग होता है। वेबसाइट सत्र का सामान्य लॉगआउट ग्राहक सॉफ़्टवेयर को प्रभावित नहीं करता। Launch केवल पहचान अमान्य होने की सूचना देता है; दूरस्थ प्राधिकरण सत्र, रनटाइम क्रेडेंशियल और डिवाइस रिलीज़ Licentivo करता है, खरीद अवधि नहीं बदलती और Launch द्वारा रखे अनलिंक भत्ते का उपयोग नहीं होता।

स्थानीय सत्र अमान्यता और सूचना कतार में जोड़ना एक ही लेनदेन में होते हैं। कतार उस समय मौजूद कनेक्शन और वातावरण स्थिर करती है, वही इवेंट ID, अनाम खाता पहचान और मूल अनुरोध से पुनः प्रयास करती है; बाद में बने कनेक्शन पुराने खाता निरस्तीकरण प्राप्त नहीं करते। पहले मूल रसीद पूछें, अनुपस्थिति की पुष्टि पर ही पुनः जमा करें; हर वातावरण का परिणाम अलग स्थायी रखें, सभी मेल खाते सफल रसीद मिलने पर ही पूर्ण दिखाएँ। नेटवर्क बाधा पर स्वतः पुनः प्रयास, क्रेडेंशियल/अनुबंध टकराव पर मैनुअल जाँच। व्यवस्थापक सिंक्रनाइज़ेशन कार्य पृष्ठ पर सूचना देखकर पुनः प्रयास कर सकता है; पुनः प्रयास नया निरस्तीकरण इवेंट नहीं बनाता।

खाता-दायरा निरस्तीकरण की सीमा Licentivo द्वारा पहली बार प्राप्त revoked_before है। सूचना लंबित रहने पर नए डेस्कटॉप लॉगिन और पहचान assertions रोकें; पूर्ण होने के बाद वास्तविक लॉगिन का auth_time सभी वातावरण रसीदों के कटऑफ़ सेकंड से सख्ती से बाद का होना चाहिए। उसी सेकंड का लॉगिन बाद में पुनः प्रमाणित हो सकता है; iat या पहचान assertion रीफ़्रेश करने से पुराना लॉगिन जारी नहीं रह सकता। वेबसाइट लॉगिन बहाली के लिए उपलब्ध रहता है। खाता दोबारा सक्षम होने पर भी दोबारा लॉगिन आवश्यक है, पुराने सत्र बहाल नहीं होते।

पुराने डेटा का माइग्रेशन

पुष्ट पुराने लाइसेंस बाइंडिंग वाली खरीद entitlement.migrated उपयोग करती है, केवल पुराना लाइसेंस ID जमा करती है, पुरानी कुंजी न पढ़ती है न जारी करती है। Licentivo माइग्रेशन की पुष्टि के बाद वर्तमान वाणिज्यिक अवधि और स्थिति सिंक्रनाइज़ करने के लिए अलग नए संस्करण का स्नैपशॉट भेजें। अपुष्ट पुराना जारी परिणाम और असंगत प्राधिकरण मैनुअल जाँच माँगते हैं; पुराने प्रबंधन कमांड स्वतः रीप्ले नहीं होते।

सामान्य SDK लॉगआउट, दूरस्थ डिवाइस अनलिंक और सर्वर-साइड पहचान निरस्तीकरण मौजूदा इंटरफ़ेस से जुड़े हैं। दूरस्थ निष्क्रियकरण अभी भी आधिकारिक SDK द्वारा जारी ऑफ़लाइन अनुमति की अवधि से सीमित है; Launch ऑफ़लाइन डिवाइस को तत्काल निरस्तीकरण मिलने का वादा नहीं करता।

खाता लॉगआउट स्वतंत्र सुरक्षा लंबित कार्य, स्थानीय सत्र लॉगआउट सारांश और प्रक्रिया-पार समन्वय उपयोग करता है; पुराना इंस्टेंस केवल अपने लॉगिन संभालता है। स्टोरेज विफलता के बाद बहाली पहले खाता निरस्तीकरण फिर जमा करती है, पहचान प्राप्त या प्राधिकरण शुरू नहीं करती; सुविधा, ऑफ़लाइन अनुमति, डिवाइस पीढ़ी और अनलिंक भत्ता अब भी Licentivo तय करता है। विवरण सुधार और दोनों पक्षों का संयुक्त परीक्षण रिकॉर्ड में है।