वेब एप्लिकेशन में लाइसेंस कुंजी समाधान, सबसे अच्छा तरीका क्या है?

Question

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

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

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

क्या किसी ने कुछ ऐसा ही किया है? क्या हम अपने दिमाग से पूरी तरह से बाहर हैं? क्या किसी के पास कोई बेहतर सुझाव है?

Comments

इसे ठीक से करने के लिए आपको बहुत समय की आवश्यकता होगी (या वे इसे तोड़ देंगे)। यह सिर्फ एक उत्पाद खरीदने के लिए बहुत सस्ता है जो जावा कार्यक्रमों की रक्षा के लिए बनाया गया है। अन्यथा बस लाइसेंस को एक जावा बाइट कोड स्निपेट बनाएं जिसे प्रोग्राम पढ़ता है और फिर अपटन कार्य करता है।

यही कारण है कि मुझे डर था, मैं तीसरे पक्ष के समाधानों पर गौर करूंगा, हालांकि हम पहले से ही बहुत अधिक परेशान हैं।

— maple_shaft

तो बस भुगतान के कारण 2 सप्ताह के बाद इसे धीमी गति से चलने दें।

@ थोरबजोरन, LOL !! ^ _ ^ जैसा कि प्रलोभन के रूप में यह परियोजना होगी इस कंपनी के साथ अतिरिक्त व्यापार की कोशिश करने और ढोल पीटने के लिए एक हानि नेता है। उच्चतम गुणवत्ता सबसे महत्वपूर्ण है। एक ही समय में हम पूरी तरह से खराब नहीं होना चाहते हैं जबकि हम शहद के बर्तन की खोज कर रहे हैं।

— maple_shaft

@ चापलूसी, एक खराब व्यवसाय योजना की तरह लगता है। फिर लेखाकारों को एकत्रित धन छोड़ दें और मैलवेयर वितरित करने पर विचार न करें।

Answer 1

इस तरह से कुछ को लागू करने के कई तरीके हैं, लेकिन यहां एक ऐसा है जिसे करना बहुत मुश्किल नहीं है:

आपको कहीं-कहीं एक सार्वजनिक रूप से उपलब्ध वेबसाइट की आवश्यकता होती है जो एक फ़ाइल को लाइसेंस कुंजी की हैश के साथ होस्ट करती है जिसे ब्लैकलिस्ट किया गया है। आप इस फ़ाइल को कैसे प्रबंधित करते हैं यह आपके ऊपर है, लेकिन फ़ाइल को केवल एक हैश प्रति पंक्ति की आवश्यकता होती है।

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

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

कठिन हिस्सा आवेदन को मृत रखने वाला है। आखिरकार, आपको इसे कहीं न कहीं आंतरिक रूप से संग्रहीत करना है, जिसका अर्थ है कि अगर यह अत्यधिक स्पष्ट है तो इसे आसानी से विकृत किया जा सकता है, और अगर यह अत्यधिक स्पष्ट नहीं है, तो भी इसे आसानी से उचित तालिका (नों) को पुनर्स्थापित करके बदला जा सकता है। फ़ाइल (फ़ाइलें)। इसलिए मैं सुरक्षा के लिए दूसरा तरीका भी सुझाता हूं।

यह पद्धति "LIVE" या "DEAD" (या कुछ समान रूप से समान) को किसी तालिका या फ़ाइल में संगृहीत करेगी, लेकिन फिर से हो जाएगी। यह अपने नमक और एक टाइमस्टैम्प के साथ hashed होना चाहिए। हर बार आपके आवेदन पर एक पेज चलता है, "LIVE" + नमक + टाइमस्टैम्प के हैशेड संस्करण के साथ इस मान की जाँच करें और फिर टाइमस्टैम्प की एक वैध श्रेणी के लिए अनुमति दें (उदाहरण के लिए, एक दिन, दो दिन, एक सप्ताह, एक महीना, आदि) ध्यान रखें कि जितना बड़ा प्रदर्शन कठिन होगा उतनी बड़ी रेंज हिट होगी।) जब तक चीजें मेल खाती हैं (या एक मैच पाया जाता है), तब तक ऐप जीवित है; अन्यथा, भले ही विशेष फ़ाइल या तालिका में मान "LIVE" हो, यह तब भी मृत होगा यदि बैकअप से पुनर्स्थापित करने का प्रयास किया जाता है क्योंकि टाइमस्टैम्प आपके थ्रेसहोल्ड के बाहर गिर जाएगा।

सारांश में (यह मान लेता है कि आपके पास लाइसेंस कुंजी की वैधता की जांच करने की कुछ प्रोग्राम विधि है , जैसे कि किसी प्रकार की चेकसम या अन्य विधि):

• CheckBlacklist
  • नमक के साथ हैश के लिए लाइसेंस कुंजी परिवर्तित करें
  • सर्वर से ब्लैकलिस्ट फ़ाइल का अनुरोध करें
  • क्या फाइल में मेरा हैश है?
  • यदि हां, तो "DEAD" + हैश + टाइमस्टैम्प (दिन को काट दिया गया हैश को स्टोर करें; घंटे + दिन + मिनट स्टोर करने की आवश्यकता नहीं)
  • यदि नहीं, तो "LIVE" + नमक + टाइमस्टैम्प (ट्रंकल) का हैश स्टोर करें
• IsKeyAlive
  • "LIVE" + नमक + ट्रंकल टाइमस्टैम्प से हैश बनाएं
  • डेडएलाइव हैश लोड करें
  • क्या वे सहमत हैं?
  • यदि हां, तो हम जीवित हैं; वापसी।
  • यदि NO, तो हम संभवतः मृत हैं, लेकिन हम अभी भी अपनी टाइमस्टैम्प विंडो में हो सकते हैं:
    • टाइमस्टैम्प से एक दिन घटाएं और हैश दोहराएं।
    • क्या अब हम सहमत हैं?
    • हाँ? TRUE लौटाएँ
    • टाइमस्टैम्प में एक दिन जोड़ें और हैश दोहराएं
    • क्या अब हम सहमत हैं?
    • हाँ? TRUE लौटाएँ
  • इस बिंदु पर, हम टाइमस्टैम्प श्रेणी से बाहर हैं, जिसका कोई मिलान नहीं है। विवरण झूठा है। (किल एप)

अब, अच्छाई जानती है कि एक मिलियन और एक तरीके से यह विफल हो सकता है। सभी संभावित तरीकों पर विचार करें और एक विश्वसनीय प्रणाली का निर्माण करें (यदि ग्राहक ब्लैकमेल फ़ाइल को डाउनलोड नहीं किया जा सकता है तो एक सही है)। परीक्षण करें, परीक्षण करें, उसका परीक्षण करें, और फिर परिनियोजन से पहले कुछ और परीक्षण करें, क्योंकि यदि यह गलत हुआ, तो आप अपने ग्राहक का विश्वास खो देंगे।

Comments

+1 एक जटिल रूप से जटिल उत्तर O_o के लिए। मैं गलत हो सकता हूं, लेकिन मुझे नहीं लगता कि यह काफी जटिल है। मैं Microsoft Office को वितरित नहीं कर रहा हूँ, यह एक ग्राहक के लिए एक कस्टम निर्मित एप्लिकेशन है। वही समस्याएं अभी भी यहां बनी हुई हैं कि इस एप्लिकेशन को होस्ट करने वाला सर्वर बाहरी सेवा के साथ संवाद करने में सक्षम नहीं हो सकता है। मुझे समझ नहीं आ रहा है कि एन्क्रिप्शन, हैश और लवण वास्तव में यहाँ क्यों आवश्यक हैं। हम वास्तव में जो चाहते हैं वह प्रभावी रूप से एक किल स्विच है।

— maple_shaft

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

— केरी शॉट

साइड नोट: यदि आप भरोसा करते हैं कि क्लाइंट को महसूस होगा कि कुछ टेबलों / फाइलों का पुनर्स्थापन बहुत मुश्किल है, तो आप ऐप को चलाने पर हर बार चेक को हटाकर जटिलता को काफी कम कर सकते हैं। उस ने कहा, किसी को यह पता लगाने में बहुत देर नहीं लगेगी कि क्या चल रहा है और इसके चारों ओर एक तरह से यह आंकड़ा है।

— कर्री शॉट

CheckBlacklist: license-server.example.com: no route to hostअब क्या? लाइसेंस सर्वर भविष्य में कभी भी अस्तित्व में नहीं हो सकता है - और मुझे नहीं बताएं कि आपकी कंपनी अभी भी बीस वर्षों में जीवित रहेगी , बल्कि यह सांख्यिकीय रूप से अनुचित है।

— पिस्कवर ने

अपने स्वयं के सर्वर का उपयोग नहीं करने सहित, इसके आसपास पाने के लिए बहुत सारे तरीके हैं। अमेज़ॅन या Google या ऐसा कुछ उपयोग करें। वैकल्पिक रूप से, चेक पर "ट्रस्ट" का निर्माण करें ताकि यदि होस्ट मृत हो तो उपयोगकर्ता ऐप का उपयोग करना जारी रख सकें। जैसा कि मैंने पोस्ट में उल्लेख किया है, एक लाख तरीके हैं जो विफल हो सकते हैं, और वास्तव में यही कारण है कि मैं इस तरह की जाँच के खिलाफ हूं। मैं इस तरह के चेक के साथ आने की बजाय अपने ग्राहकों पर भरोसा करना चाहता हूं। (अपने दम पर एक लाइसेंस कुंजी, मैं के लिए जाऊँगा। लेकिन इसे ब्लैकलिस्ट करना होगा? प्रयास के लायक नहीं, IMO।)

— केरी शॉट

Answer 2

अन्य उत्तर तकनीकी पक्ष को कवर करने का अच्छा काम कर चुके हैं। लेकिन कृपया कानूनी पक्ष पर भी विचार करें।

क्या आपको भुगतान नहीं करने पर उनके ऐप को ब्लॉक करने का भी अधिकार है? यदि आपने अनुबंध में इस फ्रंट का उल्लेख नहीं किया है, तो आपके पास ऐसा करने का अधिकार नहीं हो सकता है, भले ही भुगतान चूक (जैसे कि आप आवश्यक रूप से आपके द्वारा बेची गई किसी चीज के हकदार नहीं हैं)। इसके अलावा, कई देशों के पास "कंप्यूटर प्रोग्राम्स में हेरफेर" करने के लिए विशेष कानून हैं - जो आप करते हैं उसे इस तरह माना जा सकता है और यहां तक ​​कि आप आपराधिक दायित्व के लिए भी खुलासा कर सकते हैं।

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

अंत में, कानूनी प्रणाली पर भरोसा करना बेहतर होगा। यदि वे भुगतान नहीं करते हैं, बातचीत करते हैं, और यदि वह मदद नहीं करता है, तो बस मुकदमा करें। कई देशों में, यदि अनुबंध की स्थिति स्पष्ट है (जैसे जर्मनी में आप 20 € से कम के लिए एक Mahnbescheid प्राप्त कर सकते हैं ) पर मुकदमा करना अपेक्षाकृत दर्द रहित और सस्ता है ।

Comments

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

— maple_shaft

मैं कानूनी चैनलों का उपयोग करने पर @sleske से सहमत हूं। सुनिश्चित करें कि अनुबंध ध्वनि है, और फिर उन पर मुकदमा करें यदि वे शर्तों का उल्लंघन करते हैं। या कम से कम मुकदमा करने की धमकी दे। जो मैंने बड़ी कंपनियों के बारे में देखा है, वे विक्रेताओं को मुकदमा करने या किसी अनुबंध के उल्लंघन से बचने के लिए भुगतान करने के लिए बहुत इच्छुक हैं।

— रेशनलगीक

@maple_shaft: अमेरिका में कानूनी स्थिति के बारे में कोई विचार नहीं है, लेकिन मुझे उम्मीद है कि कानूनी स्थिति उतनी निराशाजनक नहीं है जितना आप इसे चित्रित करते हैं। वैसे भी, अगर आपको इसे लागू करने के लिए कहा गया था, तो मैं सिर्फ संभावित समस्याओं को इंगित करूंगा। यदि आप अभी भी आगे बढ़ते हैं (लिखित में, निश्चित रूप से) तो आप यह कर सकते हैं।

— साल्के

समय-सीमित लाइसेंस प्रणाली होने में कोई समस्या नहीं होगी जहां एक बार लाइसेंस समाप्त होने के बाद ऐप बेकार हो जाएगा। बहुत सारी कंपनियां ऐसा करती हैं, बड़े और छोटे - एक उदाहरण के लिए एडोब।

— जेम्स स्नेल

Answer 3

यदि वे आंतरिक रूप से मेजबानी कर रहे हैं, तो यह आपके द्वारा शिप किए जाने वाले किसी भी अन्य सॉफ़्टवेयर से कैसे अलग है? यदि आप शिपिंग, कहते हैं, तो एक डेस्कटॉप इन्वेंट्री डिस्प्ले एप्लिकेशन, और क्या करते हैं, यह पता लगाएं।

Comments

मुझे लगता है मैं सामान्य रूप से क्या करना है के बारे में उलझन में हूँ। मुझे लगता है कि आवेदन को लाइसेंस नंबर के साथ एक बाहरी वेबसर्वर के लिए अनुरोध भेजकर इसकी लाइसेंस कुंजी के खिलाफ एक रात की जांच करनी चाहिए। प्रतिक्रिया एक सफलता या विफलता होगी और एक आवेदन संदर्भ स्तर चर में संग्रहीत की जाएगी। यदि लाइसेंस कुंजी मान्य नहीं है तो आवेदन अनिवार्य रूप से "बंद" होगा। इस तरह हम जरूरत पड़ने पर बस इस लाइसेंस नंबर को "अमान्य" कर सकते हैं।

— maple_shaft

क्या आपको लगता है कि यह सरल लाइसेंस प्रमाणीकरण पृष्ठ SSL एन्क्रिप्टेड होना चाहिए? यहां तक ​​कि अगर किसी को एक पैकेट स्निफर को लागू करना था और एक वैध लाइसेंस नंबर प्राप्त कर सकता है, तो उन्हें इसके लिए उपयोगी होने के लिए आवेदन की एक वितरित प्रतिलिपि की आवश्यकता होगी, और तब भी यह बहुत उद्देश्य से बनाया गया है। मैं कल्पना नहीं कर सकता कि यह मेरे प्रत्यक्ष ग्राहक के अलावा किसी और के लिए उपयोगी है।

— maple_shaft

Answer 4

यह सिस्टम पर निर्भर करता है। क्या आपने मैग्नेटो जैसे मौजूदा ढांचे का विस्तार किया है या आपने स्क्रैच से एक पूरा आवेदन लिखा है? यदि यह बाद में है, तो लाइसेंस की आवश्यकता में निर्माण करना बहुत कठिन नहीं है। आप बस एक छोटी अवधि के लाइसेंस के साथ आवेदन देते हैं, एक जो आपके बिल के 45-दिन बाद समाप्त होता है और फिर बाद में एक स्थायी खाता देता है।

यह मानता है कि आप स्रोत को भी चालू नहीं कर रहे हैं। :)

Comments

हम स्रोत को नहीं बदल रहे हैं। हम स्रोत कोड को नियंत्रित करेंगे और नियमित रिलीज और बग फिक्स को वितरित करेंगे जब जरूरत होगी।

— maple_shaft

@maple_shaft: खैर, हमेशा बिल का भुगतान होने तक किसी भी फिक्स या अपडेट को जारी करने से इनकार करने की संभावना है, क्योंकि मुझे संदेह है कि रखरखाव प्रारंभिक खरीद में बनाया गया है या नियमित रूप से भुगतान तिथियों के साथ चल रही चीज के रूप में बेचा गया है, () आम तौर पर, लेकिन हमेशा नहीं, वार्षिक)।

— वेटिन

@Vatine पर चलने के लिए, पिछली परियोजनाओं के लिए जिनमें मजबूत लाइसेंसिंग की कमी थी, हमने भुगतान निकालने के लिए एक लीवरेज पॉइंट के रूप में दोषों का उपयोग किया है। हो सकता है कि कुछ दोष पूर्ण दुर्घटनाएं न हों।

— क्रिस्टोफर Bibbs

@maple_shaft - यदि आपके पास केवल एक ही ग्राहक है। समाधान सरल है। जब तक उनकी शेष राशि $ 0 न हो, उक्त कार्यक्रम को अपडेट प्रदान न करें।

— रामहाउंड

Answer 5

यह देखते हुए कि सिस्टम को आंतरिक रूप से होस्ट किया गया है, ऊपर वर्णित कई समाधान एक दूरस्थ सर्वर के साथ संचार करना शामिल नहीं हो सकता है।

इसके बजाय परियोजना के भीतर एक लाइसेंस फ़ाइल शामिल नहीं है जिसमें एक समाप्ति तिथि शामिल है। एक बार सिस्टम क्लॉक की समाप्ति की तारीख पार हो जाने के बाद, सिस्टम काम करना बंद कर देता है। फ़ाइल को सुरक्षित करने के लिए, छेड़छाड़ को रोकने के लिए सामग्री को एन्क्रिप्ट करें। जब उपयोगकर्ता अतिरिक्त वर्ष के लिए भुगतान करता है, या नवीनीकरण करता है, तो आप उन्हें एक नई लाइसेंस फ़ाइल भेजते हैं।

ध्यान दें कि यदि आप PHP का उपयोग कर रहे हैं, तो उपयोगकर्ता को संपादित करने के लिए कोड आसानी से उपलब्ध है, इसलिए कोई फर्क नहीं पड़ता कि आप किस तरह की सुरक्षा डालते हैं, उपयोगकर्ता आसानी से अंदर जा सकता है और इसे हटा सकता है। यदि आप ASP.NET या कुछ अन्य संकलित भाषा का उपयोग कर रहे हैं, तो यह चिंता का विषय नहीं है क्योंकि कोड को संशोधित नहीं किया जा सकता है।

Comments

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

— maple_shaft

मुझे लगता है कि जावा जैसे अधिकांश संकलित भाषाओं के साथ भी एक जार को आसानी से संकलित, अद्यतन, पुन: संकलित किया जा सकता है और फिर युद्ध में शामिल किया जा सकता है, तो कोई इसे कैसे संभालता है?

— सुदर्शन

Answer 6

(प्रकटीकरण - मैं लाइसेंस प्रबंधक प्रणालियों के एक प्रदाता एगिलिस सॉफ्टवेयर के लिए काम करता हूं )।

सबसे प्रभावी समाधान लाइसेंस पट्टे के साथ स्वचालित उत्पाद सक्रियण का उपयोग करना है । बॉक्स से बाहर यह आपको अनुमति देता है:

• ग्राहक के लाइसेंस को स्वतः सक्रिय करें। सक्रियण के समय में प्रत्येक उदाहरण स्वचालित रूप से लक्ष्य प्रणाली के आपके चुने हुए मापदंडों के लिए लॉक हो जाता है, और आपके लिए उनके द्वारा निर्धारित लाइसेंस सीमाएं आपके एप्लिकेशन पर लागू की जाएंगी (जैसे कि सुविधाओं को कॉन्फ़िगर करना, समग्र परीक्षण या सदस्यता समय सीमा निर्धारित करना)।
• एक 'लीज इंटरवल' सेट करें, जो किसी एक सक्रियण घटना की अधिकतम वैधता अवधि है। संदिग्ध क्रेडिट वाले ग्राहकों के लिए, आप इसे दो सप्ताह के लिए सेट कर सकते हैं, जिसका अर्थ है कि हर दो सप्ताह में आपका ऐप स्वचालित रूप से लाइसेंस रद्द करने की पृष्ठभूमि में 'फोन होम' करेगा। यदि वे भुगतान पर अतिदेय हैं तो आप होस्ट किए गए सर्वर में उनके लाइसेंस को अक्षम कर सकते हैं और यह अगले फोन होम पर चलना बंद हो जाएगा।
• यदि लक्ष्य प्रणाली से नेटवर्क कनेक्शन नहीं है, तो किसी भी वेब टर्मिनल पर एन्क्रिप्टेड फ़ाइलों के आदान-प्रदान के माध्यम से एक उपयोगकर्ता स्वयं-सेवा सक्रियण प्रक्रिया है। यदि आपका उपयोगकर्ता इस स्थिति में है, तो आप भुगतान प्राप्त करने की आवश्यकता के साथ उन्हें असुविधा को संतुलित करने के लिए पट्टे के अंतराल को लंबा करना चाहते हैं। एक बार जब वे भुगतान करते हैं, तो आप पट्टा अंतराल को तब तक बना सकते हैं जब तक आप चाहें, सदा तक।