अपने सॉफ़्टवेयर में लाइसेंस जोड़ें
निर्यात सुरक्षित करने के लिए लगभग 15 मिनट रखें: कॉन्फ़िगरेशन, उदाहरण, ऐप में एकीकरण और अस्वीकृति जाँच। भाषा के विकास उपकरण पहले लगे होने चाहिए।
SDK अनुरोध, डिवाइस पहचान, हस्ताक्षर, क्रेडेंशियल, कैश और हार्टबीट संभालता है। ग्राहक की कुंजी और कार्य फ़ंक्शन दें; स्वयं HTTP या activation_id सहेजना आवश्यक नहीं।
- एकीकरण पैकेज डाउनलोड करेंकंसोल में उत्पाद सेटिंग्स बनाएँ
- निर्यात फ़ाइल बनाएँअनुमति और कार्य का परिणाम जाँचें
- ऐप में जोड़ेंप्रारंभ, कार्य का प्रवेश बिंदु, बंद करना
1. कंसोल में पैकेज तैयार करें
खोलें त्वरित शुरुआत, सॉफ़्टवेयर का नाम दें, डिवाइस से बँधा या फ्लोटिंग लाइसेंस चुनें और उत्पाद बनाकर आगे बढ़ें। सिस्टम उत्पाद, नीति, परीक्षण लाइसेंस, पब्लिक key व संस्करण 1.0.0 बनाता है। भाषा चुनें, पैकेज डाउनलोड करके निकालें।
पैकेज में दो कॉन्फ़िगरेशन हैं:sdk-demo.json में आपके परीक्षण के लिए लाइसेंस key है;product.json में केवल उत्पाद सेटिंग्स व पब्लिक key है और इसे सॉफ़्टवेयर के साथ बाँट सकते हैं।
पहले एकीकरण में डिवाइस से जुड़ा लाइसेंस लें। डिफ़ॉल्ट उदाहरण में export बिना गणना है। मौजूदा उत्पाद की नीति और लाइसेंस दोनों में वही सुविधा चाहिए।
2. परिवेश जाँचें और एक फ़ाइल निर्यात करें
निकाली गई मूल डायरेक्टरी में टर्मिनल खोलें। product.json, sdk-demo.json, start.ps1, start.sh और sdk साथ रखें। भाषा और सिस्टम चुनकर कमांड चलाएँ। परिवेश जाँच सक्रियण नहीं भेजती।
सफलता का संकेत:निकास कोड 0, नीचे का आउटपुट और नई licensed-report.txt। परीक्षण विकल्प हटाकर फिर चलाएँ; SDK डिवाइस क्रेडेंशियल लौटाता है, अतिरिक्त डिवाइस स्लॉट नहीं लेता।
License OK: export is available
Export completed: licensed-report.txtपहले अनुपलब्ध विकास उपकरण लगाएँ। C/C++ को libcurl विकास फ़ाइलें भी चाहिए; MinGW में -CurlRoot दे सकते हैं। ब्राउज़र चेतावनी स्वीकार करने से SDK प्रमाणपत्र पर भरोसा नहीं करता; रनटाइम को परीक्षण सर्वर का प्रमाणपत्र विश्वसनीय होना चाहिए।
3. ग्राहक के ऐप में जोड़ें
प्रोजेक्ट में वेबसाइट इंस्टॉलर चलाएँ। नौ भाषाएँ संस्करण 0.10.0 उपयोग करती हैं। इंस्टॉल या निकालने से पहले SHA-256 जाँचा जाता है। ऐप संसाधनों में केवल product.json जोड़ें।
डाउनलोड किए एकीकरण बंडल से ऑफ़लाइन इंस्टॉल करें
SDK_ROOT को निकाले गए फ़ोल्डर के पूर्ण पथ से बदलें।
इस भाषा की चलाने योग्य फ़ाइल:। इसका व्यावसायिक प्रवेश बिंदु अपने प्रोजेक्ट में कॉपी करें; पूरा कोड देखें →
| ऐप का चरण | क्या करें |
|---|---|
| प्रारंभ या सक्रियण स्क्रीन | product.json और ग्राहक की कुंजी दें। सक्रियण के बाद अगली शुरुआत में खाली कुंजी दें। GUI ऐप में पहला ऑनलाइन सक्रियण पृष्ठभूमि कार्य में करें। |
| निर्यात बटन, शॉर्टकट, मेनू या कमांड | अपना निर्यात फ़ंक्शन RunFeature को दें। SDK अनुमति मिलने पर ही उसे बुलाता है। वही client सक्रिय रखें। |
| ऐप बंद करना | हार्टबीट रोकने के लिए client बंद करें। फ्लोटिंग सीट वापस मिलती है; जुड़े डिवाइस का पंजीकरण रहता है। |
4. जाँचें कि अनुमति न मिलने पर निर्यात रुकता है
सुनिश्चित करें कि नीति में licentivo_denied_probe नहीं है, फिर कमांड चलाएँ। गैर शून्य निकास कोड हो और denied-report.txt न बने। पहले से मौजूद नहीं होने वाला आउटपुट पथ लें।
5. आवश्यकता होने पर उपयोग गणना जोड़ें
RunMeteredFeature को फ़ंक्शन और स्थिर कार्य ID दें। SDK उपयोग आरक्षित करता, सफलता की पुष्टि और कार्य विफलता पर रद्द करता है, तथा लंबित पुष्टि दर्ज करता है।उपयोग गणना का एकीकरण और पुनःप्रयास देखें →
केवल आवश्यक SDK और product.json बाँटें। हर ग्राहक की अपनी कुंजी है। sdk-demo.json, कैश, डिवाइस क्रेडेंशियल और प्रबंधन API Key न दें। खाली cache_path उपयोगकर्ता की निजी डायरेक्टरी चुनता है।
ये तीन पहचान समझें
| नाम | कौन उपयोग करता है | उद्देश्य |
|---|---|---|
लाइसेंस key lv_lic_… | सॉफ़्टवेयर खरीदार | ऐप के भीतर सक्रिय करें। डिवाइस बदलने का अस्थायी कोड lv_tmp_… भी उसी फ़ील्ड में दें। |
| उत्पाद ID | SDK / सॉफ़्टवेयर डेवलपर | सत्यापित उत्पाद बताता है; ऐप के साथ बाँट सकते हैं। |
| प्रबंधन API key | विक्रेता का सर्वर | लाइसेंस जारी करना, नवीनीकरण व प्रबंधन स्वचालित करता है। क्लाइंट सक्रियण को इसकी ज़रूरत नहीं। |
हार्टबीट अंतराल व ऑफलाइन अवधि अलग सेट करें लाइसेंस नीतियाँ। वैधता पहले सक्रियण से शुरू होती है। मूल एकीकरण चलने के बाद फ़ीचर कोटा, फ्लोटिंग सीट और ऑफलाइन फ़ाइल सक्रियण जोड़ें।
बिना पंजीकरण भी खोल सकते हैं डेमो आज़माएँअनुरोध व रिस्पॉन्स देखने के लिए। स्वचालित लाइसेंस जारी करने हेतु पढ़ें प्रबंधन API key।
क्लाइंट SDK
फ़ंक्शन SDK को दें: अनुमति के लिए RunFeature, गणना के लिए RunMeteredFeature। अनुरोध, हस्ताक्षर, कैश और हार्टबीट SDK संभालता है।
चलाने से पहले
कंसोल में, त्वरित शुरुआततैयार पैकेज डाउनलोड करें। डेमो निजी फ़ाइल उपयोग करता है sdk-demo.json; वास्तविक ऐप में उपयोग करें product.json, ग्राहक की key स्टार्टअप पर दें। नीचे SDK डाउनलोड में सामान्य स्रोत है, आपके उत्पाद की सेटिंग्स नहीं।
हर कॉन्फ़िगरेशन फ़ील्ड का क्या अर्थ है?
{
"base_url": "https://www.licentivo.com",
"product_id": "PRODUCT_UUID",
"license_key": "",
"device_name": "Customer app",
"app_version": "1.0.0",
"trusted_keys": {
"SIGNING_KEY_UUID": "BASE64URL_PUBLIC_KEY"
},
"timeout_seconds": 10,
"allow_http": false
}base_url- लाइसेंस सर्वर URL: केवल डोमेन व पोर्ट, इसके बिना
/api/v1। स्थानीय परीक्षण में उपयोग करेंhttps://127.0.0.1:8080। product_id- इस ऐप का उत्पाद ID। लाइसेंस के उत्पाद से मिलना चाहिए।
license_key- product.json में खाली रखें। ग्राहक की key OpenWithLicense को दें:
lv_lic_…या डिवाइस बदलने का कोड:lv_tmp_…; इससे साझा कॉन्फ़िगरेशन नहीं बदलता। app_version- वर्तमान संस्करण major.minor.patch में, जैसे 1.0.0। संस्करण सीमा या रखरखाव सक्षम हो तो आवश्यक। संस्करण बदलकर फिर ऑनलाइन सत्यापित करें।
device_name- कंसोल में दिखाया डिवाइस नाम। पहचानने में मदद करता है, पर डिवाइस पहचान तय नहीं करता।
trusted_keys- उत्पाद हस्ताक्षर key ID और पब्लिक key। ऐप या प्रमाणित अपडेट के साथ बाँटें। अज्ञात रिस्पॉन्स से मिली पब्लिक key पर भरोसा न करें।
cache_path- छोड़ दें या खाली रखें; उपयोगकर्ता की निजी डायरेक्टरी अपने आप चुनी जाएगी। ऐप की अपनी निजी जगह भी दे सकते हैं।
timeout_seconds- अनुरोध की समय सीमा सेकंड में: डिफ़ॉल्ट 10, सीमा 1–120। अस्थायी नेटवर्क त्रुटि पर अधिकतम दो प्रयास।
proxy_url- वैकल्पिक प्रॉक्सी URL। Java में HTTP प्रॉक्सी; Node.js में प्रॉक्सी के लिए undici चाहिए। प्रमाणपत्र जाँच चालू रहती है।
allow_http- उत्पादन में यह मान रखें
false, HTTPS के साथ। स्थानीय परीक्षण में यह मान दे सकते हैंtrue, पर केवल localhost या लूपबैक पते के लिए।
स्वयं दर्ज करना आवश्यक नहीं device_id: SDK स्थानीय डिवाइस पहचान पढ़ता है। product.json की पब्लिक keys बाँट सकते हैं; ग्राहक keys और sdk-demo.json निजी रखें।
अपनी भाषा चुनें
यह कोड वितरित फ़ाइल जैसा है और वास्तविक निर्यात बनाता है। पर्यावरण चर सक्रियण इनपुट की जगह हैं; अपना UI लें और ऐप के जीवनकाल तक client सक्रिय रखें।
साझा इंस्टॉलेशन और संस्करण रिलीज़
भाषा और प्लेटफ़ॉर्म चुनकर प्रोजेक्ट में चलाएँ। Licentivo वेबसाइट से SDK देता है; GitHub खाता नहीं चाहिए। GitHub और सार्वजनिक रजिस्ट्री पर प्रकाशन अभी लंबित है।
संस्करण: · संस्करण पैकेज · SHA-256 चेकसम फ़ाइल · रिलीज़ मैनिफ़ेस्ट
Windows x64 और Linux x64 सत्यापित हैं। macOS और ARM64 का वास्तविक डिवाइस परीक्षण लंबित है। C/C++ बाइनरी पैकेज प्लेटफ़ॉर्म और कंपाइलर के अनुसार अलग हैं।
इंस्टॉल किए SDK का उपयोग कैसे करें
| भाषा | प्रोजेक्ट में एकीकरण |
|---|---|
| Go | import licentivo "github.com/spf86/licentivo-sdk" |
| Java | implementation(files('.licentivo-sdk/java/v0.10.0/licentivo-sdk-0.10.0.jar')) |
| C / C++ | find_package(Licentivo 0.10 REQUIRED) · target_link_libraries(MyApp PRIVATE Licentivo::C) / Licentivo::CPP |
| C# | using Licentivo; |
| Python | from licentivo import Client |
| Node.js | import {Client} from '@licentivo/sdk' |
| Rust | use licentivo::Client; |
| Ruby | require 'licentivo' |
Go, Rust और C/C++ की .licentivo-sdk डायरेक्टरी प्रोजेक्ट में रखें। अपडेट के लिए नया संस्करण चुनें; product.json और ग्राहक लाइसेंस कैश सुरक्षित रहते हैं।
SDK से सुरक्षित कार्य चलाएँ और निकलते समय client बंद करें।
正在加载代码…त्वरित प्रारंभ स्क्रिप्ट से यह फ़ाइल चलाएँ →
दूसरे ग्राहक की कुंजी लें या पूरा प्रोटोकॉल डेमो चलाएँ
पर्यावरण चर तय करके परीक्षण विकल्प बिना स्क्रिप्ट चलाएँ। लाइसेंस कुंजी प्रबंधन API कुंजी नहीं है।
सफल होने पर आउटपुट है License OK: export is available। ऐप के सक्रियण फ़ॉर्म से कुंजी लें। ग्राहक को पर्यावरण चर की जरूरत नहीं; SDK मशीन का क्रेडेंशियल सहेजता है। कुंजी लॉग में न लिखें।
पैकेज का पूरा डेमो चलाएँ
डायरेक्टरी संरचना रखकर ZIP निकालें। रखें sdk-demo.json निकाले गए मूल फ़ोल्डर में। सिस्टम चुनें, वहाँ टर्मिनल खोलकर चलाएँ:
पूरा प्रोटोकॉल डेमो उन्नत जाँच के लिए है। पहले start.ps1 या start.sh चलाएँ; ये उदाहरण सामान्य बंद करने पर डिवाइस पंजीकरण रखते हैं।
प्रबंधन उदाहरण कैसे चलाएँ?
पहले सर्वर वातावरण में सेट करें LICENTIVO_URL और LICENTIVO_API_KEY, लाइसेंस सर्वर का पता और पूरी प्रबंधन Key भरें। उदाहरण उत्पाद सूची पढ़कर HTTP स्थिति और उत्तर दिखाता है।
HTTP 200 देता है जिसमें data.items, अनुरोध सफल हुआ। 401 पर देखें कि Key पूरी है, समाप्त या रद्द तो नहीं हुई। Key बनाने और अनुमतियों के लिए देखें प्रबंधन API key।
ऐप का उदाहरण चलाएँ
उदाहरणों में सक्रियण, स्थिति, फ़ाइल निर्यात और डिवाइस छोड़ना है। Java, Python, C# में विंडो; अन्य में टर्मिनल मेनू है। कुंजी एक बार दें, फिर बहाली के लिए खाली रखें।
सफल निर्यात से licensed-report.txt बनती है। गिने जाने वाले निर्यात से पहले नीति में export की सीमा तय करें।
विंडो और मेनू डेमो निम्न स्तर का आरक्षण दिखाते हैं। नीचे RunMeteredFeature उपयोग करें; नौों भाषाएँ लंबित पुष्टि सहेजती हैं। कार्य के बीच क्रैश होने पर अपना परिणाम जाँचें।
अनुमति की स्थिति कैसे दिखाएँ?
Status और FeatureStatus स्थानीय स्थिति पढ़ते हैं; अनुरोध या पृष्ठभूमि जाँच का इंतजार नहीं। सूचनाओं से UI अपडेट करें।
| स्थिति | अर्थ |
|---|---|
active | अंतिम ऑनलाइन जाँच सफल; स्थानीय अनुमति वैध है। |
offline_valid | स्थानीय हस्ताक्षर वैध है; शुरू होने के बाद ऑनलाइन पुष्टि सफल नहीं हुई। |
verification_required | उपयोग योग्य हस्ताक्षर नहीं। सक्रिय करें या ऑनलाइन अपडेट करें। |
| expired / revoked / released | सर्वर ने अनुमति स्पष्ट रूप से अस्वीकार की। सुरक्षित कार्य रोकें। |
quota_exhausted | इस गिने जाने वाले अनुरोध ने सीमा पार की; अन्य अधिकृत सुविधाएँ उपलब्ध हैं। |
allowed स्थानीय अनुमति की वैधता बताता है; गिनी जाने वाली सुविधा को इकाइयाँ माँगनी होती हैं। lease_valid_until हस्ताक्षरित कैश की सीमा है, लाइसेंस का अंत नहीं। code, request_id, retryable त्रुटि, लॉग ID और पुनः प्रयास की संभावना बताते हैं।
मेथड, कॉलबैक और पैकेज उपयोग के लिए डाउनलोड में sdk/README.md देखें। वेबसाइट संस्करण पैकेज और साझा इंस्टॉलर देती है; सार्वजनिक रजिस्ट्री प्रकाशन लंबित है।
इसे ऐप में कहाँ रखें?
| ऐप का चरण | क्या करें |
|---|---|
| स्टार्टअप या key देने के बाद | OpenWithLicense कॉल करें (C++ में constructor व Start)। SDK सक्रिय करके नीति के अनुसार हार्टबीट शुरू करता है। |
| सशुल्क फ़ीचर से पहले | फ़ंक्शन RunFeature को दें; गणना के लिए RunMeteredFeature उपयोग करें |
| ऐप चलने के दौरान | client चलने दें; SDK नीति के अंतराल पर हार्टबीट भेजता है। |
| ऐप बंद होने पर | Close / Dispose / Destroy हार्टबीट रोकता, फ्लोटिंग सीट लौटाता और बँधे डिवाइस का पंजीकरण रखता है। |
| उपयोगकर्ता अनबाइंड करे तब | Deactivate कॉल कर client बंद करें। |
तालिका के नाम कार्य बताते हैं; अपनी भाषा के उदाहरण का सही नाम लें। हार्टबीट, ऑफलाइन कैश और ऑनलाइन रीफ़्रेश हेतु देखें हार्टबीट और ऑफलाइन उपयोग।
प्रबंधन API key
ऑर्डर सिस्टम से स्वचालित लाइसेंस जारी करने या सर्वर से लाइसेंस डेटा पढ़ने के लिए प्रबंधन API Key लें। यह आपके विक्रेता कार्यक्षेत्र का प्रतिनिधित्व करती है।
क्लाइंट को कौन सी key चाहिए?
| क्रेडेंशियल | किसे दें | किस काम के लिए |
|---|---|---|
lv_api_…प्रबंधन API key | आपका अपना सर्वर | उत्पाद, नीति, लाइसेंस बनाएँ; डिवाइस, उपयोग व ऑडिट देखें |
lv_lic_…लाइसेंस key | ग्राहक का सॉफ़्टवेयर | सक्रिय, सत्यापन, हार्टबीट व डिवाइस छोड़ना |
| उत्पाद पब्लिक key | क्लाइंट के साथ दें | सर्वर लाइसेंस हस्ताक्षर जाँचें |
ग्राहक सॉफ्टवेयर में लाइसेंस जांच के लिए लाइसेंस कुंजी पर्याप्त है। प्रबंधन API Key पूरा कार्यक्षेत्र नियंत्रित करती है; इसे ग्राहक सॉफ्टवेयर या सार्वजनिक पेज में न रखें।
key बनाएँ
- कार्यक्षेत्र Owner से लॉगिन करके खोलें API Key और API Key बनाएँ दबाएँ।
- काम के अनुसार नाम दें, जैसे “ऑर्डर सिस्टम”। केवल पढ़ने के लिए Read only, लाइसेंस बनाने या बदलने के लिए Read/write चुनें। वैधता 1–365 दिन हो सकती है।
- सहेजते ही पूरी Key कॉपी करें; वह केवल एक बार दिखती है। इसे सर्वर के निजी कॉन्फ़िग या पर्यावरण चर में रखें।
पहला प्रबंधन अनुरोध भेजें
यह उदाहरण उत्पाद सूची पढ़ता है। सेट करें LICENTIVO_URL लाइसेंस सर्वर URL पर और सेट करें LICENTIVO_API_KEY अभी बनाई पूरी key पर, फिर चलाएँ:
curl "$LICENTIVO_URL/api/v1/products?limit=25" \
-H "Authorization: Bearer $LICENTIVO_API_KEY"यह Bash/macOS/Linux का तरीका है। Windows PowerShell में लें curl.exe; वातावरण चर है $env:LICENTIVO_URL और $env:LICENTIVO_API_KEY। नौ भाषाओं के पूरे अनुरोध भी यहाँ SDK पृष्ठ का सर्वर प्रबंधन API Key विकल्प।
सफलता पर HTTP 200 व data.items। Bearer Key में लॉगिन कुकी या CSRF नहीं।
अधिकार व अमान्यता प्रबंधन
Read only Key संसाधन देख सकती है; Read/write उत्पाद, नीतियां और लाइसेंस बना-बदल सकती है। खाते, टीम, सिस्टम सेटिंग और भुगतान के लिए अधिकृत खाते का लॉगिन चाहिए, प्रबंधन Key नहीं।
लीक या अनुपयोगी Key कंसोल में रद्द करें। बदलने के लिए Rotate दबाएं; पुरानी Key तुरंत निष्क्रिय होगी। फिर सर्वर का कॉन्फ़िग अपडेट करें।
प्लान की API सीमा में सक्रियण, सत्यापन, हार्टबीट और रिलीज़ गिने जाते हैं। यहां के प्रबंधन अनुरोध इसमें नहीं गिने जाते।
उत्पाद और लाइसेंस API
ऑर्डर के बाद अपने सर्वर से लाइसेंस जारी करें: पहले उत्पाद और नीति बनाएं, फिर हर ग्राहक का लाइसेंस। पहले दो आम तौर पर एक बार ही सेट होते हैं।
पहले कंसोल में लिखने की अनुमति वाला प्रबंधन API key। नीचे के उदाहरण में Authorization: Bearer 你的管理Key; यह key विक्रेता के सर्वर पर रखें।
उत्पाद का data.id, product_id है और नीति का data.id, policy_id। जारी होने पर लाइसेंस के data.id और data.key सहेजें। पूरी कुंजी सिर्फ एक बार मिलती है; सूची का key_prefix सक्रियण के काम नहीं आता।
सक्रियता से पहले सीमित लाइसेंस में,expires_at और first_activated_at null हैं। पहली सफल सक्रियता से अवधि; बदलाव नई अवधि नहीं देता।
आगे का प्रबंधन
| विधि व पथ (/api/v1 के बिना) | उद्देश्य व अनुरोध बॉडी |
|---|---|
GET /products | उत्पाद सूची पढ़ें। उत्तर में data.items रिकॉर्ड की सरणी और data.total कुल संख्या है। |
GET /licenses/{id} | लाइसेंस, पहली सक्रियता व समाप्ति देखें। |
POST /licenses/{id}/renew | नवीनीकरण, जैसे {"days":30}। मूल लाइसेंस रहता है। |
POST /licenses/{id}/revoke | रद्द करें; अनुरोध बॉडी {}। |
GET /products/{id}/public-keys | लॉगिन बिना उत्पाद सार्वजनिक key पढ़ें। SDK वितरण में विश्वसनीय key निश्चित रखें। |
GET /activations | डिवाइस बाइंडिंग व सत्र देखें। |
सूची पृष्ठ में उपयोग limit=25&offset=0, limit अधिकतम 100। अन्य तर्क व संरचना यहाँ OpenAPI फ़ाइल; हर लाइसेंस मॉडल के लिए बाईं ओर का विषय देखें।
ब्राउज़र सत्र से कॉल कैसे?
ब्राउज़र कुकी वाले लेखन अनुरोध में X-CSRF-Token चाहिए। पहले GET /api/v1/auth/csrf, फिर data.csrf_token इस हेडर में रखें। Bearer Key में CSRF नहीं चाहिए।
SDK लाइसेंस कॉल
भाषा और ऑपरेशन चुनकर SDK कॉल करें। यह सक्रियण, डिवाइस पहचान, हस्ताक्षर जाँच, कैश, हार्टबीट और उपयोग आरक्षण, पुष्टि व रद्द करना संभालता है।
उदाहरण में client शुरुआत से आता है, path निर्यात पथ और exportReport / export_report आपका फ़ंक्शन है। उपयोग गणना का jobID ऐप में सहेजी गई स्थिर ID है।
पूरा कोड देखें → · त्वरित शुरुआत · उपयोग गणना का एकीकरण और पुनःप्रयास देखें →
SDK अनुमति मिलने पर ही कार्य चलाता है। RunFeature उपयोग नहीं काटता; RunMeteredFeature आरक्षण, सफलता पर पुष्टि और विफलता पर रद्द करता है। मूल कार्य से पुनःप्रयास केवल पुष्टि करता है, पूरा कार्य दोहराता नहीं।
HTTP अनुरोध और उत्तर खोलें (कस्टम क्लाइंट या समस्या जाँच)
नीचे का प्रोटोकॉल SDK में पहले से लागू है। इन नौ SDK का उपयोग करने वाले ऐप को इसे दोबारा लागू करने की आवश्यकता नहीं है।
आठ इंटरफ़ेस लाइसेंस और डिवाइस पहचान जाँचते हैं; लॉगिन कुकी, CSRF या प्रबंधन कुंजी नहीं चाहिए। निकलने पर फ्लोटिंग सत्र लौटता है; जुड़े डिवाइस का पंजीकरण रहता है।
सक्रियता, सत्यापन या हार्टबीट के बाद अनुमति कैसे जाँचें?
- HTTP 200 देखकर पढ़ें
data.activation_id। अगले सत्यापन, हार्टबीट, गणना और अनबाइंड में यह ID दें। - पहले से विश्वसनीय उत्पाद सार्वजनिक key से जाँचें
data.leaseजांचें, फिर उत्पाद, डिवाइस, वैधता और सुविधाएं मिलाएं। payload को JSON में पढ़ना भर लाइसेंस की वैधता सिद्ध नहीं करता। - SDK पहले दो चरण स्वयं करता है। RunFeature कार्य से पहले अनुमति जाँचता है; RunMeteredFeature गणना के आरक्षण, पुष्टि और रद्द करने को संभालता है।
SDK हस्ताक्षरित कैश रखता और नीति अनुसार हार्टबीट भेजता है। केवल टाइमआउट पर वैध कैश न मिटाएं। रद्द, रिलीज़ या समाप्ति की स्पष्ट अस्वीकृति पर SDK के परिणाम अनुसार संरक्षित सुविधाएं रोकें।
डिकोड payload फ़ील्ड का मतलब?
नीचे उदाहरण केवल डेटा समझाता है। स्वयं हस्ताक्षर जांचते समय मिले payload के मूल bytes लें; JSON को क्रम बदलकर या फिर serialize करके न जांचें।
दोबारा प्रयास, हार्टबीट व बिलिंग
सक्रियता, अनबाइंड व गणना में अनिवार्य Idempotency-Key, अधिकतम 80 अक्षर, बिना खाली स्थान। नए काम के लिए नया मान; उसी अनुरोध को दोहराने पर वही मान और body रखें। सत्यापन और हार्टबीट में वैकल्पिक; SDK अपने अनुरोध ID संभालता है।
हर सफल सक्रियण, सत्यापन, हार्टबीट या हटाना एक API कॉल है। विफल और समान idempotent replay फिर नहीं गिने; CheckFeature स्थानीय है। Consume सुविधा उपयोग काटता, यह API सीमा नहीं; quantity उपयोग संख्या है।
हार्टबीट, ऑफ़लाइन अवधि व स्थायी अनुसार लाइसेंस नीतियाँ से नियंत्रित है।payload.expires_at मौजूदा हस्ताक्षरित कैश की समाप्ति है, लाइसेंस की अंतिम समाप्ति नहीं। अंतिम तिथि लाइसेंस विवरण में देखें।
हार्टबीट और ऑफलाइन उपयोग
दोनों सेटिंग लाइसेंस नीति में हैं, लेकिन अलग हैं: ऑनलाइन कितनी बार सर्वर से संपर्क हो, और संपर्क न होने पर कितने समय तक चल सके।
हार्टबीट अंतराल: कितनी बार सत्यापन
हार्टबीट अंतराल (सेकंड) दें 600, चलते समय SDK लगभग हर 10 मिनट में हार्टबीट भेजता है। हर सफल अनुरोध नए नियम लेता है और स्थानीय लाइसेंस कैश अपडेट करता है।
600–86400 सेकंड दें। दें 0 नियत हार्टबीट बंद करता है। ऐप फिर भी स्वयं जाँच या अपडेट कर सकता है। समय में 0–10% यादृच्छिक देरी जुड़ती है; अंतराल 600 सेकंड से कम नहीं होता।
डिवाइस से जुड़ी लाइसेंस की कैश वैध हो तो पहले अनुमति लौटती है, फिर पृष्ठभूमि में ऑनलाइन जाँच होती है, टाइमर बंद होने पर भी। केवल ऑनलाइन और फ्लोटिंग सीट के लिए सर्वर की पुष्टि जरूरी है।
ऑफ़लाइन अवधि: सर्वर न मिले तो कितनी देर चले
ऑफ़लाइन मोड में तीन विकल्प हैं। हार्टबीट अंतराल नहीं बदलता।
- निर्धारित अवधि की अनुमति
- 24 घंटे रखने पर कैश अंतिम सफल ऑनलाइन सत्यापन से अधिकतम 24 घंटे वैध है। इस समय नेटवर्क या सर्वर अस्थायी बंद होने पर सॉफ्टवेयर चल सकता है। उसके बाद सफल ऑनलाइन सत्यापन चाहिए।
- ऑफ़लाइन विकल्प अनुमति नहीं
- शुरू होते समय सर्वर से सफल संपर्क जरूरी है; विफल अनुरोध पर डिस्क कैश प्रवेश नहीं देता। चलते समय मिला छोटा हस्ताक्षर अधिकतम वैध है
max(10, 心跳间隔)सेकंड; ऐप सत्यापन व फ़ीचर अनुमति जाँच जारी रखे। - स्थायी ऑफ़लाइन उपयोग की अनुमति
- स्थानीय हस्ताक्षर लंबे समय और नेटवर्क विफलता में भी अनुमति जांच सकता है। 30 दिन का लाइसेंस 30 दिन में समाप्त होगा; स्थायी ऑफ़लाइन उसे स्थायी लाइसेंस नहीं बनाता।
API उपयोग करता है offline_mode इन तीन विकल्पों का क्रम है limited, none, permanent। निश्चित ऑफ़लाइन अवधि में,offline_seconds 1–31536000 सेकंड; अन्य दोनों में 0।
ये संयोजन कैसे चलते हैं?
| हार्टबीट / ऑफ़लाइन सेटिंग | वास्तविक व्यवहार |
|---|---|
| 10 मिनट / 24 घंटे | ऑनलाइन हर 10 मिनट सत्यापन। ऑफ़लाइन अंतिम सफल जांच से अधिकतम 24 घंटे उपयोग |
| 10 मिनट / स्थायी ऑफ़लाइन | हर 10 मिनट प्रयास; सफलता पर नियम अपडेट, संपर्क न हो तो मान्य हस्ताक्षर उपयोग। |
| 0 / स्थायी ऑफ़लाइन | वैध कैश से शुरू करें, तय अनुरोध नहीं। स्वयं सत्यापन या refresh करने पर सर्वर से संपर्क होगा |
| 0 / 24 घंटे | नियत हार्टबीट नहीं, कैश फिर भी समाप्त। ऐप स्वयं सत्यापन तय करे; हार्टबीट बंद से ऑफ़लाइन अवधि नहीं बढ़ती। |
ऑफ़लाइन अवधि हार्टबीट अंतराल से लंबी रखें। हर घंटे हार्टबीट लेकिन सिर्फ 1 मिनट ऑफ़लाइन होने पर हस्ताक्षर अगली हार्टबीट से पहले समाप्त होगा; अलग सत्यापन जरूरी है।
नीति बदलने पर पुराने लाइसेंस बदलते हैं?
हां। बदले हार्टबीट या ऑफ़लाइन नियम पुराने और नए संबंधित लाइसेंस पर अगले सफल सक्रियण, सत्यापन या हार्टबीट में लागू होते हैं। SDK कैश बदलता है। उसी Idempotency-Key की retry मूल अनुरोध का परिणाम देती है।
ऑफ़लाइन डिवाइस पुराने हस्ताक्षरित नियम इस्तेमाल करता है। केवल नेटवर्क लौटने से कैश नहीं बदलता; एक अनुरोध सफल होना चाहिए। ऐप नेटवर्क लौटने पर refresh कर सकता है।
वैध दिन, डिवाइस सीमा और सुविधाएं हर लाइसेंस में सहेजे जाते हैं। नीति बदलने से वे अपने आप नहीं बदलते। लाइसेंस पेज पर अधिकार बदलें।
स्पष्ट ऑनलाइन रिफ्रेश
ये तरीके हमेशा सर्वर से संपर्क करते हैं, स्थायी ऑफ़लाइन और बंद हार्टबीट में भी। सफलता हस्ताक्षर बदलती है; नेटवर्क विफलता refresh त्रुटि देकर वैध कैश रखती है। स्पष्ट रद्द या रिलीज़ होने पर कैश मिटता है।
| भाषा | कॉल करने का तरीका |
|---|---|
| Go | client.RefreshOnline(ctx) |
| Java | client.refreshOnline() |
| C | ln_refresh_online(client) |
| C++ | client.RefreshOnline() |
| C# | await client.RefreshOnline() |
| Python | client.refresh_online() |
| JavaScript | await client.refreshOnline() |
सफल refresh एक सक्रियण API अनुरोध गिना जाता है। नीति पहले बंद हार्टबीट चालू करे तो अपनी भाषा का StartHeartbeat बुलाएं। ऑफ़लाइन डिवाइस रद्द या रिलीज़ की सूचना नहीं पाते।
डिवाइस बाइंडिंग
एक डिवाइस के लाइसेंस में सॉफ्टवेयर और कैश दूसरे सामान्य कंप्यूटर पर कॉपी करने से पुराना अधिकार नहीं मिलता।
SDK कंप्यूटर कैसे पहचानता है?
हर शुरुआत में SDK OS पहचान और उत्पाद ID से डिवाइस हैश बनाता है। सर्वर हस्ताक्षर में यह हैश रहता और स्थानीय जांच में भी मिलता है।
Windows से MachineGuid, Linux से machine-id, macOS से IOPlatformUUID पढ़ता है। मूल पहचान अपलोड नहीं होती, केवल बना हैश। कॉन्फ़िग का पुराना device_id वास्तविक स्थानीय पहचान नहीं बदलता।
A की फ़ाइलें B पर कॉपी करने से क्या होगा?
- A सक्रिय होकर अपने हैश से बँधा हस्ताक्षर पाता है।
- B अपनी पहचान से अलग हैश, A कैश अस्वीकार करता है।
- B को ऑनलाइन सक्रिय करना होगा। सीमा 1 और A अभी बंधा हो तो सर्वर B अस्वीकार करता है।
ग्राहक कंप्यूटर कैसे बदलें?
ग्राहक पुराना कंप्यूटर हटाकर नया सक्रिय करे। पुराना खराब हो तो कंसोल के डिवाइस सक्रियण में बंधन छोड़ें। कंप्यूटर बदलने से लाइसेंस समाप्ति फिर शुरू नहीं होती।
सिस्टम दोबारा इंस्टॉल करने से पहचान बदल सकती है और नया डिवाइस सक्रियण लग सकता है। पूरा OS क्लोन, नकली पहचान या बदला क्लाइंट अधिक मजबूत हमले हैं; केवल यह हैश उन्हें रोकने की गारंटी नहीं देता।
लंबे ऑफ़लाइन में A का पुराना हस्ताक्षर तुरंत रिलीज़ नहीं जानता; सफल सर्वर अनुरोध पर स्थिति बदलती है। लंबी ऑफ़लाइन अवधि दूरस्थ नियंत्रण लागू होने में देर करती है।
भाषाओं में समान डिवाइस हैश
SHA256(UTF8(
"LicenovaDevice/v2\n"
+ lower(product_id) + "\n"
+ lower(trim(OS_machine_identity))
))कोटा और बिलिंग
डिवाइस सीमा इस्तेमाल हुए डिवाइस, API सीमा सफल सर्वर अनुरोध गिनती है। दोनों अलग; डिवाइस संख्या से API उपयोग नहीं निकलता।
कौन से ऑपरेशन API सीमा में गिने जाते हैं?
| कार्रवाई | गिना जाता है? |
|---|---|
| सफल सक्रियता, सत्यापन, हार्टबीट या रिलीज़ | प्रति सफलता 1; एक दिन के अलग हार्टबीट अलग गिने जाते हैं। |
| विफल अनुरोध, जैसे गलत key या अपर्याप्त सीमा | नहीं गिना जाता |
| वही Idempotency-Key से पुनःप्रयास व मूल परिणाम | फिर नहीं गिना जाता |
| स्थानीय CheckFeature या हस्ताक्षरित कैश जाँच | नहीं गिना; सर्वर अनुरोध नहीं |
| प्रबंधन API Key से लाइसेंस देखें या जारी करें | इस रनटाइम API सीमा में नहीं |
बारबार अनुरोध से डिवाइस कई बार गिना जाता है?
नहीं। एक चक्र में उसी उत्पाद का वही डिवाइस एक बार, लेकिन हर सफल हार्टबीट API उपयोग है। रिलीज़ पुराना उपयोग नहीं मिटाता।
जैसे 100 डिवाइस, दिन में 8 घंटे, माह में 22 दिन, हर 10 मिनट हार्टबीट। केवल हार्टबीट में 105,600 कॉल। साथ में 100 सक्रियताएँ व प्रति डिवाइस दैनिक अतिरिक्त सत्यापन, कुल 107,900 कॉल।
अतिरिक्त सत्यापन उदाहरण की धारणा; वास्तविक संख्या ऐप अनुसार। यहाँ ऑनलाइन उपयोग अनुमान डिवाइस, अवधि व अंतराल बदलें।
प्लान से अतिरिक्त शुल्क कैसे लगता है?
100,000 API शामिल, अतिरिक्त 0.0001 USD: 120,000 सफल कॉल में 20,000 अतिरिक्त और API शुल्क 2 USD।
अतिरिक्त उपयोग व्यवस्थापक मूल्य पर शेष से कटता है। कुल राशि cents में round, केवल नई वृद्धि कटती; छोटे प्रति कॉल मूल्य में बार-बार rounding शुल्क नहीं।
अतिरिक्त डिवाइस शुल्क अलग: अतिरिक्त संख्या × प्रति डिवाइस मूल्य। कठोर सीमा खत्म पर अतिरिक्त अनुरोध अस्वीकार; शेष राशि कम हो तो अगला भुगतान अनुरोध भी। विफल अनुरोध उपयोग नहीं बढ़ाता।
असीमित API में अतिरिक्त शुल्क नहीं। 0 में मुफ्त कॉल नहीं, पहली सफल कॉल से अतिरिक्त नियम। सीमा और कीमत देखें वर्तमान प्लान, ये संख्या केवल उदाहरण हैं।
प्लान की अवधि और कोटा कब शुरू होते हैं?
1, 3, 6 या 12 महीने खरीदें। कुल राशि एक बार दें; सफल भुगतान पर प्लान शुरू होगा।
सक्रिय होने से कोटा मासिक रीसेट होगा। 31 जनवरी को शुरू होने पर फरवरी के अंतिम दिन, फिर 31 मार्च। शेष कोटा आगे नहीं जुड़ेगा।
खरीद न हो तो व्यवस्थापक नियम UTC माह में। डिवाइस शुल्क मासिक बिल, अतिरिक्त API तुरंत शेष से। खरीद के बाद उसी अवधि की सीमा, default सीमा जुड़ती नहीं।
सीमा या राशि कम होने से अनुरोध अस्वीकार हो तो पुराने ऑफ़लाइन हस्ताक्षर मूल नियम में वैध रहते हैं। विक्रेता कंसोल से डिवाइस छोड़ सकता, runtime API सीमा नहीं कटती।
फ्लोटिंग सीट
Floating लाइसेंस एक साथ चलने वाले प्रोग्राम सीमित करता है। बारी-बारी उपयोग में हर कंप्यूटर का अलग लाइसेंस नहीं लेना पड़ता।
उदाहरण
100 कंप्यूटर और 10 सीट में पहले 10 प्रोग्राम चलते, 11वां “सीट भरी” पाता है। एक प्रोग्राम और SDK सामान्य बंद होने पर दूसरा सीट ले सकता है। एक कंप्यूटर में दो प्रोग्राम भी दो सीट लेते हैं।
नीति में सेट करें
फ़्लोटिंग सीटें चुनें और सीमा 10 रखें। हार्टबीट अंतराल कम से कम 600 सेकंड; सीट लीज़ उससे लंबी, जैसे 1200 सेकंड। हार्टबीट नवीनीकरण करता है; क्रैश या डिस्कनेक्ट पर लीज़ समाप्त होने से सीट मुक्त होगी।
Floating लाइसेंस लीज़ में छोटा नेटवर्क कटाव सहता है। ऑफ़लाइन समय भी लीज़ तक सीमित; स्थायी ऑफ़लाइन या फ़ाइल से पूरी ऑफ़लाइन पहली सक्रियण नहीं।
ऐप कोड में और क्या सँभालें?
Open/Start और सामान्य बंद तरीका लें। SDK हर client का अलग सत्र ID बनाता है। हर export नया client न बनाएं; पूरे ऐप जीवन में एक रखें।
पुराना floating कैश अगले शुरू में सीट अपने आप नहीं लौटाता। लीज़ समाप्त हो तो फिर सक्रिय होकर सीट लेकर काम करें।
ऑफ़लाइन सक्रियता
पूरे ऑफ़लाइन कंप्यूटर पर पहली सक्रियण के लिए अनुरोध फ़ाइल और हस्ताक्षरित उत्तर लें। USB से अनुरोध ऑनलाइन कंप्यूटर तक ले जाएं।
चरण
- लक्ष्य कंप्यूटर में SDK कॉन्फ़िग लेकर OfflineRequest("activate") कॉल करें और फ़ाइल रखें। बनाने में सर्वर संपर्क नहीं चाहिए।
- ऑनलाइन कंप्यूटर में कंसोल का ऑफ़लाइन फ़ाइल सक्रियण खोलें, अनुरोध अपलोड और उत्तर डाउनलोड करें। अंतिम ग्राहक अपने पोर्टल में भी कर सकता है।
- उत्तर वापस लाकर ImportOffline में मूल अनुरोध और उत्तर दें। SDK हस्ताक्षर, अनुरोध ID, संस्करण और मशीन पहचान जांचकर कैश रखता है।
- CheckFeature से अनुमति जांचें। ऑफ़लाइन कंप्यूटर को ऑनलाइन हार्टबीट नहीं चाहिए; अवधि लाइसेंस नीति तय करती है।
फ़ाइल सक्रियण केवल ऑफ़लाइन की अनुमति वाले बंधे लाइसेंस में है। अनुरोध 30 दिन वैध। सीमित लाइसेंस सर्वर मंजूरी से शुरू होता, क्योंकि उत्तर import का समय सर्वर नहीं जानता।
ऑफ़लाइन अनबाइंड कैसे?
मूल कंप्यूटर में OfflineRequest("deactivate") बनाएं। SDK पहले कैश मिटाता; फिर विक्रेता या पोर्टल को अनुरोध दें। मिटाना पुरानी प्रतियां न होने का प्रमाण नहीं। जल्दी रोकने के लिए नियमित ऑनलाइन जांच नीति लें।
हर भाषा में नाम
| भाषा | अनुरोध बनाएँ | रिस्पॉन्स आयात करें |
|---|---|---|
| Go | OfflineRequest("activate") → []byte | ImportOffline(requestBytes, responseBytes) |
| Java | offlineRequest("activate") → JSON पाठ | importOffline(requestText, responseText) |
| JavaScript | offlineRequest("activate") → object | importOffline(requestObject, responseObject) |
| C | ln_offline_request(client, "activate") | ln_import_offline(client, requestText, responseText) |
| C++ / C# | OfflineRequest("activate") → JSON पाठ | ImportOffline (C++ पाठ, C# बाइट) |
| Python | offline_request("activate") → dict | import_offline(requestDict, responseDict) |
C में लौटे टेक्स्ट को ln_free_string से मुक्त करें। उत्तर फ़ाइल का असल डेटा दें, web API का बाहरी data आवरण नहीं।
फ़ीचर उपयोग सीमा
निर्यात की अनुमति और मासिक 500 निर्यात अलग नियम हैं। RunFeature अनुमति जाँचता है; RunMeteredFeature सफलता के बाद उपयोग की पुष्टि करता है।
प्रति माह 500 एक्सपोर्ट दें
नीति में export सुविधा और सीमा दें: export, 500, मासिक। मूल नियम में खत्म होने पर अस्वीकार। अतिरिक्त अनुमति हो तो अधिकतम संख्या दें; सिस्टम ऑर्डर प्रणाली के लिए अतिरिक्त उपयोग रखता है।
दैनिक और मासिक सीमा UTC मध्यरात्रि पर reset; कुल सीमा नहीं। सीमा बदलने से पुराना उपयोग नहीं मिटता।
सफल निर्यात के बाद उपयोग की पुष्टि
अपना कार्य फ़ंक्शन SDK को दें। नए काम के लिए नया ID; पुनःप्रयास में वही ID, सुविधा और मात्रा रखें। अलग प्रक्रियाओं में एक ID साथ न चलाएँ।
| भाषा | उपयोग गणना वाले कार्य का कॉल |
|---|---|
| Go | client.RunMeteredFeature(ctx, "export", 1, jobID, exportReport) |
| Java | client.runMeteredFeature("export", 1, jobID, this::exportReport) |
| Node.js | await client.runMeteredFeature("export", 1, jobID, exportReport) |
| Python | client.run_metered_feature("export", 1, job_id, export_report) |
| C# | await client.RunMeteredFeature("export", 1, jobID, ExportReport) |
| C++ | client.RunMeteredFeature("export", 1, jobID, exportReport) |
| Rust | client.run_metered_feature("export", 1, &job_id, || export_report())? |
| Ruby | client.run_metered_feature("export", 1, job_id) { export_report } |
| C | ln_run_metered_feature(client, "export", 1, job_id, export_report, context) |
पहले export कोटा तय करें। Windows में -Metered -OperationID export-job-001 या Linux/macOS में --metered --operation-id export-job-001 जोड़ें।
कार्य सफल पर पुष्टि विफल हो तो वही ID केवल पुष्टि दोहराता है, कार्य नहीं। कार्य के बीच क्रैश स्वचालित दोहराव रोकता है। स्थायी परिणाम जाँचकर ResolveMeteredFeature से पुष्टि या रद्द करें। दूर की गणना और स्थानीय कार्य एक लेनदेन नहीं हैं।
जब आरक्षण प्रवाह स्वयं नियंत्रित करना हो
- इस निर्यात के लिए काम का ID बनाएँ और सहेजें।
- एक इकाई Reserve करें, pending पर ही निर्यात करें। committed यानी पूरा; दोहराएँ नहीं।
- निर्यात सफल होने और परिणाम सहेजने के बाद Commit से उपयोग की पुष्टि करें।
- निर्यात पूरा होने से पहले विफल हो तो Cancel से आरक्षण हटाएँ; इकाइयाँ नहीं कटेंगी।
आरक्षण डिफ़ॉल्ट 15 मिनट, UTC अवधि बदलने पर पहले समाप्त। सीधे API में reservation_seconds 30–3600 सेकंड रख सकते हैं।
| भाषा | आरक्षित करें | पुष्टि / रद्द |
|---|---|---|
| Go | Reserve(ctx, "export", 1, jobID) | Commit / Cancel(ctx, hold.ID, jobID) |
| Java / Node.js | reserve("export", 1, jobID) | commit / cancel(id, jobID) |
| C | ln_reserve(client, "export", 1, jobID) | ln_commit / ln_cancel(client, id, jobID) |
| C++ / C# | Reserve("export", 1, jobID) | Commit / Cancel(id, jobID) |
| Python | reserve("export", 1, jobID) | commit / cancel(id, jobID) |
जवाब के फ़ील्ड कैसे पढ़ें?
| फ़ील्ड | अर्थ |
|---|---|
| reservation_id / operation_id | आरक्षण और मूल काम का ID; पुनः प्रयास में वही मान दें। |
| status / expires_at | स्थिति और समय सीमा: pending अधूरा, committed उपयोग कटा, canceled छोड़ा गया, expired अवधि खत्म। |
| consumption.used / reserved | इस अवधि के पुष्ट उपयोग / सभी सक्रिय आरक्षणों में रोकी गई इकाइयाँ। |
| consumption.limit / remaining | मूल सीमा / उपलब्ध मूल इकाइयाँ। remaining = max(0, limit - used - reserved); अनुमत अतिरिक्त उपयोग शामिल नहीं। |
| consumption.quantity / overage | इस काम की इकाइयाँ / मूल सीमा से अधिक पुष्ट उपयोग; ग्राहक से भुगतान नहीं लिया जाता। |
| consumption.period / reset_at | UTC उपयोग अवधि / अगला रीसेट; आजीवन सीमा में reset_at = null। |
अनुरोध, जवाब और फ़ील्ड प्रकार के लिए रनटाइम API में Reserve, Commit और Cancel देखें।
सफलता के बाद रद्द या फिर निर्यात न करें। ID और परिणाम रखकर Commit दोहराएँ। आरक्षण खत्म हो तो मिलान के लिए काम सहेजें। दूरस्थ गणना और स्थानीय काम एक परमाणु लेनदेन नहीं हैं।
Consume तुरंत उपयोग काटता है। विफल काम न कटे तो आरक्षण लें। सुविधा के सभी गणना अनुरोध ऑनलाइन हैं और प्लेटफ़ॉर्म के चार शुल्क योग्य API कार्यों में नहीं गिने जाते।
संस्करण और रखरखाव
स्थायी खरीद में उपयोग जारी रहता, लेकिन हमेशा मुफ्त upgrade जरूरी नहीं। रखरखाव अवधि प्रकाशन तिथि अनुसार योग्य संस्करण तय करती है।
वर्तमान संस्करण खरीदें, एक वर्ष अपडेट शामिल
नीति स्थायी और रखरखाव 365 दिन दें, पहली सक्रियण से शुरू। सॉफ्टवेयर संस्करण में 1.0.0, 1.1.0 आदि असल प्रकाशन तिथि से दें।
रखरखाव में प्रकाशित संस्करण चलते रहेंगे। बाद के नए संस्करण अस्वीकार, पुराने चलते हैं। नवीनीकरण पर लाइसेंस के अधिकार और ग्राहक में अवधि बढ़ाएं।
ऐप अपना संस्करण कैसे भेजता है?
sdk-demo.json में app_version जैसे 1.1.0 दें। रखरखाव हो तो पहले कंसोल में प्रकाशित करें। तीन संख्या वाला 1.2.3 प्रारूप ही है। बेचे अधिकार बचाने के लिए प्रकाशन तिथि नहीं बदलती।
केवल 1.x के लिए 1.0.0–1.999.999 दें, बिना रखरखाव। अपडेट के बाद ऑनलाइन नया हस्ताक्षर लें; पुराना कैश नए संस्करण को अनुमति नहीं देता।
डाउनलोड दें
संस्करण रिकॉर्ड में HTTPS डाउनलोड और SHA-256 हो सकते हैं। पोर्टल केवल योग्य संस्करण दिखाता है। रिकॉर्ड लिंक देता, इंस्टॉलर अपलोड या अपने आप अपडेट इंस्टॉल नहीं करता।
ग्राहक पोर्टल
ग्राहक विक्रेता कंसोल खोले बिना लाइसेंस, डिवाइस देख और बंधन हटा सकते हैं।
विक्रेता पहले ग्राहक ईमेल जोड़ता है
जारी करते समय ईमेल या अधिकार व ग्राहक में दें। भेजें ग्राहक पोर्टल लिंक ग्राहक को दें। उस ईमेल पर एक बार का लॉगिन लिंक मिलता, 15 मिनट वैध। लॉगिन सत्र 24 घंटे रहता है।
ग्राहक केवल उस ईमेल के लाइसेंस देखता है, उत्पाद प्रबंधन, बिल या दूसरों का डेटा नहीं। पहले व्यवस्थापक सेटिंग में ईमेल सेवा जोड़ें।
कंप्यूटर बदलते समय मूल key खो जाए तो?
- ग्राहक लाइसेंस का जुड़ा ईमेल भरकर मिले लॉगिन लिंक को खोलता है। लिंक केवल लॉगिन करता, डिवाइस नहीं हटाता।
- मेरे डिवाइस/सत्र में पुराना, अनबाइंड व बदलाव फिर पुष्टि।
- पेज पर अस्थायी कोड है, अधिकतम 15 मिनट और एक सफल सक्रियण के लिए। ग्राहक कॉपी या अपने ईमेल पर भेजने का विकल्प ले सकता है।
- नए कंप्यूटर में ऐप खोलकर सक्रियण पर अस्थायी कोड भरें। SDK कंप्यूटर पहचानता, मूल लाइसेंस बांधता और डिवाइस प्रमाण रखता है। फिर restart और हार्टबीट प्रमाण लेते हैं; कोड समाप्त होने से सक्रिय कंप्यूटर प्रभावित नहीं।
केवल डिवाइस बंधन बदलता है। ID, मूल समाप्ति, सुविधाएं, ग्राहक और उपयोग रहते हैं; नया लाइसेंस जारी नहीं होता। नया डिवाइस मूल नीति माने और खाली जगह होनी चाहिए।
सॉफ़्टवेयर विक्रेता क्या बदलें?
वर्तमान SDK लें। लाइसेंस कुंजी का फील्ड यह भी ले सकता है lv_tmp_ अस्थायी कोड; कॉन्फ़िग में दें license_key काफी है; Start, सत्यापन और हार्टबीट सामान्य रूप से काम करते हैं। SDK निजी कैश में डिवाइस का क्रेडेंशियल रखता है;cache_path खाली रह सकता है। फ़ाइल वर्तमान उपयोगकर्ता के ऐप डेटा में रखें; इंस्टॉलर के साथ न बाँटें।
सफल उपयोग के बाद ऐप साफ कर सकता है license_key खाली; वही उत्पाद, सार्वजनिक key व cache_path, पुनः शुरू होने पर SDK डिवाइस प्रमाण बहाल करता है। ग्राहक को अस्थायी कोड सहेजना या दोबारा भरना नहीं पड़ता। उपयोग सफल होने तक इनपुट रखें, ताकि कनेक्शन टूटने पर फिर कोशिश हो।
कोड समाप्त या पृष्ठ बंद हो
पोर्टल में फिर लॉगिन कर अप्रयुक्त कोड देखें। समाप्त होने पर रिलीज़ डिवाइस के पास कोड देखें/लें से दोबारा लें; नया बदलाव नहीं गिना जाता। प्रयुक्त कोड फिर नहीं चलता, पुराने रिकॉर्ड से बार-बार लेकर सीमा भी नहीं टलती। अगला बदलाव करने को वर्तमान डिवाइस हटाएं।
नया कंप्यूटर पूरी तरह ऑफ़लाइन हो
नए कंप्यूटर में अस्थायी कोड देकर SDK अनुरोध निकालें। कोड समाप्त होने से पहले ऑनलाइन कंप्यूटर के पोर्टल से उत्तर लें और नए में import करें। नीति में ऑफ़लाइन बंधे डिवाइस सक्रियण अनुमत हो। मूल अवधि रहती; मशीन अधिकार और प्रमाण वाला उत्तर सुरक्षित रखें।
अनबाइंड सीमा व पुराने कंप्यूटर की स्थिति
नीति में प्रति लाइसेंस प्रति UTC माह स्वयं रिलीज़ सीमा दें। 0 नया पोर्टल बंधन हटाना बंद करता है। दोहराए क्लिक, कोड देखना या समाप्त अप्रयुक्त कोड फिर लेना अतिरिक्त नहीं गिना जाता। सीमा पोर्टल और ग्राहक ऑफ़लाइन आवेदन पर है, विक्रेता के हाथ से रिलीज़ या मूल कुंजी वाली सॉफ्टवेयर कॉल पर नहीं।
दूर से बंधन हटाना अगली ऑनलाइन जांच रोकता है। पुराना ऑफ़लाइन कैश ऑनलाइन या समाप्ति तक चलता है। स्थायी कैश तुरंत दूर से नहीं रोका जा सकता; जल्द रद्द करने के लिए नियमित ऑनलाइन नीति लें। दूसरे कंप्यूटर में सामान्य कॉन्फ़िग, प्रमाण और कैश कॉपी अलग पहचान के कारण अस्वीकृत है।
ग्राहक पोर्टल लाइसेंस उपयोग संभालता है। सॉफ्टवेयर ऑर्डर और बिक्री भुगतान विक्रेता के अपने सिस्टम में रहते हैं।
इवेंट सूचनाएँ
सक्रियण, नवीनीकरण या रद्द होने पर Licentivo आपके सर्वर को बताकर ऑर्डर, ग्राहक और सहायता सिस्टम मिला सकता है।
सूचना एंडपॉइंट जोड़ें
लाइसेंस घटना सूचना में HTTPS पता और घटनाएं दें। हस्ताक्षर secret एक बार दिखता, प्राप्तकर्ता सर्वर पर रखें। उत्पादन में स्थानीय या निजी नेटवर्क पता नहीं।
मिलने के बाद हस्ताक्षर जाँचें
X-Licentivo-Timestamp, X-Licentivo-Event और मूल body पढ़ें। timestamp + '.' + event ID + '.' + body पर secret से HMAC-SHA256 निकालें। sha256= लगाकर X-Licentivo-Signature स्थिर समय में मिलाएं। अब से 5 मिनट से अधिक अंतर अस्वीकार।
event ID से दोहराव हटाएं। हस्ताक्षर जांचकर transaction या queue में स्थायी रखें, फिर 2xx दें। दोहराए event में 2xx, ऑर्डर कार्य दोबारा नहीं।
विफलता में क्या होता है?
अधिकतम 8 स्वचालित प्रयास, बढ़ता विराम। कंसोल में HTTP स्थिति, समय, त्रुटि और हाथ से फिर भेजना। घटना और लाइसेंस कार्य एक transaction; restart पर भेजना जारी।
घटनाएं: बनाना, अपडेट, नवीनीकरण, रद्द, सक्रियण, रिलीज़, सुविधा उपयोग, आने वाली समाप्ति, समाप्ति और रखरखाव बदलाव। सूचना में केवल prefix, पूरी कुंजी नहीं।
सामूहिक कार्य और नीति बदलाव
समूह में लाइसेंस जारी, नवीनीकरण या रद्द करें। पुराने अधिकार बदलने से पहले प्रभाव देखें।
सामूहिक जारी या आयात
लाइसेंस में समूह जारी/import चुनकर उत्पाद और नीति दें। हर पंक्ति नाम, ईमेल या customer,customer_email header वाला CSV दें। अधिकतम 100 पंक्तियां। परिणाम डाउनलोड और पूरी कुंजियां रखें।
एक आइटम विफल तो पूरा समूह लागू नहीं। टाइमआउट में वही डेटा फिर भेजें; request ID मूल परिणाम लौटाता, फिर जारी नहीं।
सामूहिक नवीनीकरण या निरस्तीकरण
बाएं लाइसेंस चुनकर समूह नवीनीकरण या रद्द दबाएं। header वर्तमान पेज चुनता; पेज बदलने पर चयन रहता, अधिकतम 100। filter बदलना, पेज छोड़ना या refresh चयन मिटाता है।
नवीनीकरण के अतिरिक्त दिन दें। असक्रिय में अवधि, सक्रिय में मूल समाप्ति, समाप्त में अब से बढ़ेगी। रद्द से पहले चयन खोलकर ग्राहक जांचें; वापस नहीं होता। Read only सदस्य ये काम नहीं कर सकता।
पुराने लाइसेंस पर नई नीति लागू करें
- लाइसेंस नीतियों में नए नियम रखें।
- एक उत्पाद के पुराने लाइसेंस चुनें, नीति लागू करें और नई नीति चुनें।
- अवधि, डिवाइस/सीट, सुविधाएं, उपयोग और रखरखाव बदलाव देखें। सीट नई सीमा से ज्यादा या मोड बदलने पर सक्रिय डिवाइस हो तो पहले उन्हें संभालें।
- पुष्टि के बाद लागू करें। अगला ऑनलाइन सत्यापन नया हस्ताक्षर लेता; पूरा ऑफ़लाइन कैश दूर से नहीं बदलता।
पूर्वावलोकन 10 मिनट वैध। लाइसेंस या नीति बदले तो फिर देखें। नए दिन मूल पहली सक्रियण से समाप्ति गिनते; पहले तिथियां जांचें।
सामान्य प्रश्न
पहले त्रुटि कोड, फिर संबंधित सेटिंग देखें। उत्तर का request_id लॉग में काम खोजता है। पूरी key लॉग या चित्र में न दें।
सक्रियता विफल हो तो क्या जाँचें?
सर्वर पहुंच, सही उत्पाद ID, पूरा कोड और इसी उत्पाद का लाइसेंस जांचें। सर्वर तैनात होने तक ग्राहक का कंप्यूटर आपका 127.0.0.1 पते से; वह ग्राहक के अपने कंप्यूटर का पता है।
| त्रुटि कोड | पहला चरण |
|---|---|
LICENSE_INVALID | उत्पाद ID, पूरी key व लाइसेंस उत्पाद देखें |
LICENSE_EXPIRED | समाप्ति देखें; जरूरत पर विक्रेता नवीनीकरण करें |
LICENSE_REVOKEDDEVICE_RELEASED | लाइसेंस रद्द/डिवाइस छोड़ा; SDK कैश हटाता है |
DEVICE_LIMIT_REACHED | लाइसेंस स्थान पूर्ण; पुराना छोड़ें या सीमा बढ़ाएँ |
API_QUOTA_EXCEEDED | API कड़ी सीमा समाप्त; अवधि व प्लान देखें |
API_BALANCE_INSUFFICIENT | API अतिरिक्त बैलेंस कम; मुद्रा व परिवेश देखें |
MONTHLY_QUOTA_EXCEEDED | प्लेटफ़ॉर्म डिवाइस सीमा; लाइसेंस सीमा अलग |
IDEMPOTENCY_CONFLICT | एक Key अलग बॉडी; नए काम में नई Key, पुनःप्रयास मूल बॉडी |
IDEMPOTENCY_EXPIRED | पुराना उत्तर/बाइंडिंग अमान्य; स्थिति देखें, नए काम में नई Key |
ऑफ़लाइन भी क्यों चलता है?
ऑफ़लाइन में भी SDK स्थानीय हस्ताक्षर, उत्पाद, डिवाइस, सुविधाएं और समाप्ति जांचता है; केवल सर्वर अनुरोध नहीं होता। समाप्त कैश या ऑनलाइन रद्द/रिलीज़ की स्पष्ट अस्वीकृति आगे उपयोग रोकती है।
हस्ताक्षर या डिवाइस जाँच क्यों विफल है?
सार्वजनिक कुंजी न मिलना, दूसरे उत्पाद का कैश या दूसरे कंप्यूटर पर कॉपी कैश विफल हो सकता है। जांचें trusted_keys की key ID और सार्वजनिक कुंजी इसी उत्पाद की हैं; फिर देखें कि सिस्टम बदला या दोबारा इंस्टॉल हुआ है।
SDK बताता है clock rollback : घड़ी पीछे जाँची जाए। सही करके ऑनलाइन रिफ्रेश।
पूरा त्रुटि उत्तर
{
"error": {
"code": "LICENSE_REVOKED",
"message": "License was revoked"
},
"request_id": "99999999-9999-4999-8999-999999999999"
}| फ़ील्ड | अर्थ और कार्रवाई |
|---|---|
error.code · string | स्थिर त्रुटि ID से निर्णय, message शब्दों से नहीं। |
error.message · string | पढ़ने योग्य कारण, निदान या ग्राहक संदेश हेतु। |
request_id · UUID | लॉग का सर्वर HTTP ID; लाइसेंस या Idempotency-Key नहीं। |
400/415: फ़ील्ड या Content-Type सुधारें; 401: प्रबंधन Key जांचें; 403: संबंधित लाइसेंस त्रुटि संभालें; 409: सीमा, सत्र या idempotency टकराव देखें; 429: Retry-After तक रुकें। टाइमआउट या 5xx को विराम देकर दोहराएं। लेखन में मूल ID और body रखें, ताकि दो बार न गिना जाए।
JSON उत्तर कैसे पढ़ें?
सफल उत्तर data और request_id; विफलता में error.code, error.message और request_id। त्रुटि कोड व request_id से अधिकांश समस्या मिलती है।
ईमेल, भुगतान या परिनियोजन में देखें सहायता व समस्या समाधान।
API के सभी फ़ील्ड देखें OpenAPI फ़ाइल।