सवाल 30 दिन के समय के परीक्षण को लागू करना [बंद]


वहां इंडी मैक डेवलपर्स के लिए प्रश्न:

मैं गैर-बुरे फैशन में 30-दिवसीय समय परीक्षण कैसे कार्यान्वित करूं? Prefs में काउंटर डालना एक विकल्प नहीं है, क्योंकि महीने में एक बार प्रीफ़ को पोंछना औसत उपयोगकर्ता के लिए कोई समस्या नहीं है। एक छिपी हुई फाइल में काउंटर डालने से कहीं थोड़ा सा डोडी लगता है - एक उपयोगकर्ता के रूप में मुझे नफरत है जब ऐप यादृच्छिक फाइलों के साथ मेरी हार्ड ड्राइव को छिड़कता है। कोई विचार?


44
2018-01-07 14:54


मूल


एक सुझाव: एक्स तिथि के बाद से इसे 30 दिनों के बजाय, इसे लगातार उपयोग के एक्स घंटे बनाने के बारे में कैसे? 30-दिवसीय परीक्षण के विपरीत, एक्स-घंटे-वास्तविक-उपयोग परीक्षण संभवतः मुझे आपके यूआई के आस-पास एक सतही रूप लेने के 31 दिन बाद वास्तविक कार्य में ऐप लागू करने के लिए समय के साथ छोड़ देगा। यह वास्तव में आपके प्रश्न का उत्तर नहीं देता है (जहां परीक्षण जानकारी डाली जाती है), केवल इसे थोड़ा संशोधित करता है (वहां क्या रखा जाना चाहिए: पहले लॉन्च की बनाम बनाम मिनटों की संख्या)। - Peter Hosey
स्टीम के माध्यम से तैनाती पर विचार करें। वे आपको आवश्यक सभी डीआरएम का प्रबंधन करते हैं। - Thorbjørn Ravn Andersen
सॉफ़्टवेयर विकसित करते समय मैंने कॉन्फ़िगरेशन फ़ाइल संस्करण और रजिस्ट्री कुंजी रखने की प्रक्रिया का उपयोग किया है। लेकिन दोनों ब्रेक अगर उपयोगकर्ता मशीन को स्वरूपित करता है और इसे पुनः स्थापित करता है। मशीन प्रारूपित होने के बाद समाप्ति के बाद भी 30 दिन का परीक्षण फिर से उपयोग किया जा सकता है। लेकिन माइक्रोसॉफ्ट सॉफ्टवेयर के मामले में, जिन्हें प्रारूप के बाद भी इंस्टॉल नहीं किया जा सकता है। वह तर्क क्या हो सकता है? - Nisha
ओपनएसएसएल का उपयोग कर आवेदन के लिए लाइसेंस कुंजी बनाने के तरीके पर एलन ओडगार्ड द्वारा एक साफ लेख है। आप अपनी लाइसेंस कुंजी में एक समाप्ति तिथि शामिल कर सकते हैं और हमेशा एक वैध लाइसेंस की आवश्यकता होती है, लेकिन आपकी वेबसाइट पर 30-दिन के लाइसेंस सौंपती है। यदि कोई उपयोगकर्ता परीक्षण लाइसेंस का अनुरोध करता रहता है, तो आप कम से कम इसे गिनने में सक्षम होंगे और अंततः उन्हें मना कर देंगे। sigpipe.macromates.com/2004/09/05/... - uliwitness


जवाब:


यह मुद्दा कोको-देव मेलिंग सूची पर बार-बार आता है और सर्वसम्मति उत्तर हमेशा सबसे आसान चीज संभव है। निर्धारित हैकर्स सभी ओवर-इंजीनियर समाधान के अलावा सभी को तोड़ देंगे। और वे सॉफ़्टवेयर के लिए वैसे भी भुगतान करने की संभावना नहीं है। 80/20 समाधान के लिए जाएं: आसान समाधान जो 20% प्रयास के लिए 80% प्रभाव प्राप्त करता है। इस मामले में, ~ / लाइब्रेरी / एप्लिकेशन समर्थन / your.app.com / में कुछ डालना। यदि आप चीजों को थोड़ा सा खराब करना चाहते हैं तो आप फ़ाइल को कुछ निर्दोष नाम दे सकते हैं। उपयोगकर्ता डिफ़ॉल्ट का उपयोग करना भी आसान है।

आप जो भी करें, नहीं मैक पता या अन्य हार्डवेयर आईडी का उपयोग करें। नेटवर्क होम निर्देशिका वाले उपयोगकर्ता (उदा। साझा लैब सेटिंग में) आपको नफरत करेंगे। हार्डवेयर आईडी का उपयोग करना सिर्फ बुरा है।

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

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


59
2018-01-07 19:58



क्या आप कृपया बता सकते हैं कि एक हैश हार्डवेयर आईडी का उपयोग क्यों बुरा है? - superarts.org


मैं उन चीजों को लागू करने का सुझाव दूंगा जो कम घुसपैठ कर रहे हैं और सामान्य उपयोगकर्ता से एक महीने की अवधि में अनइंस्टॉल या खरीदने के लिए बच सकते हैं।

  1. परीक्षण-सीरियल नंबर की एक विशेष श्रृंखला का उपयोग करें जो इसमें समाप्ति तिथि संग्रहीत करता है। आप सीरियल नंबर के भीतर समाप्ति तिथि संग्रहीत करने के लिए एन्क्रिप्शन का उपयोग कर सकते हैं।
  2. अब एक कॉन्फ़िगरेशन फ़ाइल बनाएं जो एन्क्रिप्टेड प्रारूप में डेटा संग्रहीत करती है और सीरियल नंबर रखती है।

इसके अतिरिक्त कॉन्फ़िगरेशन फ़ाइल में इन चीजों को लागू करें।

  1. हर बार जब उपयोगकर्ता एप्लिकेशन शुरू करता है तो समय / तिथि का नोट बनाएं।
  2. ध्यान दें कि समय की अवधि खुली थी।

टाइमस्टैम्प के लॉगिंग करके आप इन कामकाज से बच सकते हैं:

  1. यदि उपयोगकर्ता कंप्यूटर की तारीख को उलट देता है, तो आप जान लेंगे कि उस दिन ऐप पहले ही चल रहा था। उपयोगकर्ता के महीने के 1 और 3 दिन पर ऐप चलाएं। अब 30 दिनों के बाद तारीख को उलट देता है और इसे दूसरे महीने में सेट करता है। अब कॉन्फ़िगरेशन फ़ाइल द्वारा आप जान लेंगे कि ऐप पहले से ही 1 और 3 पर चला है, इसलिए उपयोगकर्ता ने कंप्यूटर पर गड़बड़ की तारीखें बनाई हैं।
  2. आइए मान लें कि हर बार जब उपयोगकर्ता आपके ऐप को पहली तारीख को 5 वें महीने तक सेट करता है। अपने आवेदन चलने के समय को लॉग इन करके आप देखेंगे कि यदि दिन में कुल घंटे 24 से अधिक हो तो उपयोगकर्ता चारों ओर बेवकूफ़ बना रहा है।

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

मैं इंटरनेट का सुझाव नहीं दूंगा क्योंकि ऐप हर बार सर्वर से कनेक्ट करने का प्रयास करता है जब लोग परेशान हो जाते हैं। इसके अलावा, किसी को संदेह हो सकता है कि आप उपयोगकर्ताओं के कुछ व्यक्तिगत डेटा को अपने सर्वर पर भेजने की कोशिश कर रहे हैं।

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


24
2018-01-07 17:30





इस पर विचार करो। आपके सॉफ़्टवेयर के कितने संभावित उपयोगकर्ता वहां हैं, केवल 30 दिनों के लिए इसे ठोस रूप से उपयोग करने के लिए खुजली?

मुझे संदेह है कि कहीं अधिक सामान्य मामला है: उपयोगकर्ताओं को एक नया सॉफ्टवेयर पैकेज मिलता है जो उनके पास एक समस्या हल करता है था lifehacker.com जैसी साइट पर। सॉफ्टवेयर डाउनलोड हो जाता है, संक्षेप में खेला जाता है, फिर एक तरफ रखा जाता है। शायद यह एमपी 3 फिसलने वाला सॉफ्टवेयर है और उस समय उसके पास कोई सीडी नहीं है। या वे उस दिन व्यस्त हैं, लेकिन वे जल्द ही उस सॉफ्टवेयर की समीक्षा करने के लिए दौर प्राप्त करेंगे।

30 दिन पास शायद अधिक केवल तभी वे एक सीडी खरीदते हैं, किसी प्रकार की 'समस्या' का सामना करते हैं और याद करते हैं, 'आह, यह परीक्षण संस्करण मैंने डाउनलोड किया है! मैंने इसे फिर से कहां रखा? कोई फर्क नहीं पड़ता कि। कभी भी इस्तेमाल किए बिना, 'परीक्षण' का समय समाप्त हो गया है।

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


11
2018-01-07 18:55



एमएमएम, बहुत अच्छा मुद्दा, धन्यवाद। अब, यह ऐप के प्रकार और यह क्या करता है, इस पर निर्भर करता है। मैं निश्चित रूप से इस पर विचार करूंगा। - svintus


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

मैं इसे 14 लॉन्च तक सीमित कर दूंगा, या 120 मिनट के उपयोग की तरह कुछ।

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


7
2018-01-08 00:57





कम से कम बुरा तरीका यह है कि उपयोगकर्ता को एक महीने के बाद प्रोग्राम को हटाने या इसके लिए भुगतान करने के लिए कहें;)


5
2018-01-07 14:56



दुर्भाग्यवश, उपयोगकर्ता "बुराई" होंगे जो खुद को पकड़कर नहीं रखेंगे।


हमने इसे हमारे क्लाइंट एप्लिकेशन में से एक के लिए किया था। यह विंडोज़ के लिए .NET में किया गया था, लेकिन मैक में एक ही सिद्धांत लागू किया जा सकता है।

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

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

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

यह एक कार्यक्रम के लिए अधिक हो सकता है, लेकिन यह निश्चित रूप से काम करता है।


2
2018-01-07 15:14



डाउनवोट क्यों? अगर मेरी सुरक्षा में कोई दोष है, तो मैं जानना चाहता हूं कि यह क्या है क्योंकि हम इसे अपने ऐप पर लागू कर रहे हैं। - David Brunelle
एक संभावित मुद्दा यह है कि मैक पते को बदलने के लिए यह छोटा है, इसलिए यदि आप अपनी अद्वितीय आईडी के रूप में मैक पते का उपयोग कर रहे हैं, तो आपकी सुरक्षा आसानी से बाधित होती है। (मैं वह नहीं था जिसने आपका उत्तर बीटीडब्ल्यू घटाया) - Chinmay Kanchi
उल्लेख करने के लिए भूल गए, हम कंप्यूटर हार्डवेयर से अन्य आईडी का भी उपयोग करते हैं, लेकिन मुझे नहीं पता था कि मैक एड्रेस को बदलना संभव था। - David Brunelle
हाँ यह सिर्फ एक रजिस्ट्री कुंजी है जिसे आप बदलते हैं। डिवाइस (या विंडोज़ जो मैं भूल जाता हूं) पर रीबूट पर नया मैक पता "स्पूफेड" होता है, और डिवाइस तब तक नए पते का उपयोग करता है जब तक कि reg कुंजी वहां होती है। इसके अलावा मैं आपको +1 करता हूं, मुझे आपका दृष्टिकोण पसंद है, यह सभी के खिलाफ चला जाता है "अगर वे चाहते हैं तो वे इसे भी परेशान करेंगे यदि भीड़ को परेशान न करें"। - Anonymous Type
शायद सबसे बड़ा मुद्दा यह है कि यदि इंटरनेट डाउन हो गया है, तो आपका सर्वर डाउन हो गया है या ऐप इंस्टॉल को किसी भी कारण से प्रमाणित नहीं किया जा सकता है? यह उस पल से जटिल हो जाता है। - Jason Fuerstenberg


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

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

या आप इसे WinZip की तरह कर सकते हैं (या ऐसा करने के लिए उपयोग किया जाता है?): 30-दिन का परीक्षण प्रदान करें और प्रत्येक लोड पर बस एक स्क्रीन पॉप-अप करें जो दिखाता है कि आप इसका कितना समय उपयोग कर रहे हैं और खरीदारी के लिंक हैं।


2
2018-01-07 16:51





मैं अपने आईओएस ऐप का 30-दिवसीय लाइट संस्करण पेश करता था जो कि इंस्टॉल डेटा और इंस्टॉल डेटा डेटा में विभिन्न रिकॉर्ड तिथियों को एम्बेड करता था जिसे उपयोगकर्ता अपने कंप्यूटर पर डाउनलोड कर सकता था।

यदि उपयोगकर्ता एक cheapskate था और बस लाइट संस्करण को पुनर्स्थापित किया और डेटा को फिर से आयात करने की कोशिश की, तर्क यह नोटिस करेगा कि कम से कम एक तिथि 30 दिनों से अधिक पुरानी थी और ऐप अपनी स्थापना तिथि को जल्द से जल्द इस तारीख को सेट करेगा फ़ाइल, इसे फिर से समाप्त करने की प्रतिपादन।

पूर्ण भुगतान संस्करण में, यह तर्क मौजूद नहीं था और डेटा फ़ाइल को आसानी से आयात किया जा सकता था।

यह इस डेटा माइग्रेशन में लोगों का समर्थन करने वाला दर्द था (चूंकि ऐप्स एक दूसरे से पूरी तरह से सैंडबॉक्स किए गए हैं) और कुछ अन्य उपयोगकर्ताओं को लगा कि लाइट संस्करण उनके लिए पर्याप्त था, इसलिए उन्होंने कभी अपग्रेड नहीं किया।

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

सब कुछ, उपयोगकर्ताओं को भुगतान करने के लिए यह सबसे अच्छी रणनीति थी।


2
2018-04-19 05:06