IOS 12 में स्वचालित रूप से उत्पन्न पासवर्ड

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

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

अधिकार और दायित्व

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

यदि एप्लिकेशन आपकी साइट (तथाकथित "साझा क्रेडेंशियल") के साथ साझा किए गए खातों के उपयोग का समर्थन करता है, तो यह कदम पहले से ही पीछे है। यह पहले से ही पीछे हो सकता है, और यदि एप्लिकेशन बाह्य लिंक या बाहरी "URL" के प्रसंस्करण के लिए किसी अन्य तंत्र का समर्थन करता है।

वैसे भी, इस संगतता को जोड़ने के बाद आवेदन में एक नया "एंटाइटेलमेंट" होगा ।

इस अधिक सामान्य संगतता के अलावा, आवेदन में "क्षमता" "ऑटोफ़िल क्रेडेंशियल प्रदाता" भी होना चाहिए - यह आवेदन की अनुमति देता है, अगर उपयोगकर्ता द्वारा अनुमति दी जाती है, तो सिस्टम द्वारा पेश किए गए लॉगिन और पासवर्ड का उपयोग करने के लिए। इस संगतता को जोड़ने से AutoFill क्रेडेंशियल प्रदाता Entitlement अनुमति प्रकट होगी ।

वैसे, यह और अन्य सुविधाओं का जोड़ केवल Apple डेवलपर प्रोग्राम के सदस्यों के लिए उपलब्ध है।

एप्लिकेशन द्वारा उपयोग किए जाने वाले प्रोविज़निंग प्रोफाइल में निम्नलिखित दो विशेषताएं भी शामिल होनी चाहिए।

प्रयुक्त निर्भरताएँ

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

सबसे पहले, संबंधित फ्रेमवर्क का स्वचालित जोड़ पहली बार "काम" नहीं कर सकता है: जब मैं "एक्सकोड" संस्करण 10.1 की मेरी कॉपी से एक वास्तविक डिवाइस पर एप्लिकेशन लॉन्च करता हूं, तो "प्रमाणीकरण प्रमाणीकरण" की कमी के कारण आवेदन तुरंत "दुर्घटनाग्रस्त" हो गया। मैन्युअल रूप से ढांचे को हटाने और संबंधित घटकों की सूची में वापस जोड़ने से समस्या हल हो गई।

दूसरे, स्वचालित रूप से एक रूपरेखा जोड़ना "आवश्यक" के रूप में चिह्नित करता है। यदि आपका आवेदन 12 से नीचे "" "आईओएस" संस्करणों के तहत काम करने की संभावना का अर्थ है, तो यह निचले संस्करणों के "ऑपरेटिंग सिस्टम" के तहत स्टार्ट-अप चरण पर दुर्घटना का कारण बन जाएगा। "प्रमाणीकरण सेवा" केवल संस्करण 12 सिस्टम के लिए उपलब्ध हैं। इस समस्या को "वैकल्पिक" के रूप में रूपरेखा को चिह्नित करके हल किया गया है।

पाठ बॉक्स समर्थन

पाठ फ़ील्ड के साथ कार्यक्षमता का समर्थन करने के लिए, textContentType प्रोटोकॉल के चर textContentType UITextInputTraits । UITextField वर्ग, जिसका उपयोग एप्लिकेशन में लॉगिन और पासवर्ड दर्ज करने के लिए सबसे अधिक किया जाता है, पहले से ही हमारे द्वारा आवश्यक प्रोटोकॉल की आवश्यकताओं को लागू करता है।

textContentType प्रकार का एक क्षेत्र है जिसमें केवल स्थिरांक का एक सेट है। इस समय हमें जो कुछ भी चाहिए, वह है newPassword , का उपयोग किया जा रहा एक नया पासवर्ड दर्ज किया जा रहा है (वर्तमान पासवर्ड दर्ज करने के लिए उपयोग किए password साथ भ्रमित नहीं होना चाहिए)।

 let passwordTextField = UITextField() if #available(iOS 12, *) { passwordTextField.textContentType = .newPassword } 

textContentType मान सेट करना एक "API" एक्सेसिबिलिटी चेक में लपेटा गया है, क्योंकि, सामान्य कार्यक्षमता की तरह, यह स्थिरांक केवल "iOS 12" से शुरू होता है।

सामग्री प्रकार के अलावा, पाठ फ़ील्ड को सुरक्षित डेटा प्रविष्टि प्रदान करनी चाहिए:

 passwordTextField.isSecureTextEntry = true 

यद्यपि एप्लिकेशन अच्छी तरह से दर्ज किए गए पासवर्ड को प्रदर्शित करने और छिपाने की कार्यक्षमता प्रदान कर सकता है, जो हमारे समय में लोकप्रिय है, उत्पन्न पासवर्ड केवल तभी पेश किया जाएगा जब झंडा इस समय true हो।

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

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

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

 let userNameTextField = UITextField() userNameTextField.keyboardType = .emailAddress userNameTextField.textContentType = .username 

पासवर्ड आवश्यकताएँ

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

 if #available(iOS 12, *) { passwordTextField.passwordRules = UITextInputPasswordRules(descriptor: "required: upper; required: lower; required: digit; minlength: 8;") } 

संपत्ति भी केवल "iOS 12" से शुरू हो रही है।

संपत्ति का प्रकार UITextInputPasswordRules । आरंभीकरण - एक डिस्क्रिप्टर स्ट्रिंग का उपयोग करना। संभाल में एक सरल वाक्यविन्यास होता है और इसमें अर्धवृत्त के साथ सूचीबद्ध सरल पासवर्ड आवश्यकताएं होती हैं। प्रत्येक आवश्यकता एक कुंजी-मूल्य जोड़ी है, जो एक बृहदान्त्र द्वारा अलग होती है। कुंजी नियम का प्रकार है (उदाहरण के लिए, "आवश्यक रूप से शामिल है" - required ), और मान वह तत्व है जो इस नियम का पालन करना चाहिए (उदाहरण के लिए, अंक - digit )।

ऊपर दिए गए उदाहरण में, वर्णनकर्ता का अर्थ है:

• required: upper - कम से कम एक पूंजी पत्र की उपस्थिति की आवश्यकता होती है;
• required: lower - कम से कम एक लोअरकेस पत्र के लिए समान;
• required: digit - कम से कम एक लोअरकेस अंक के लिए समान;
• न्यूनतम minlength: 8 - न्यूनतम लंबाई आठ वर्ण है।

संभव कुंजियों और मूल्यों की एक विस्तृत सूची NSHipster वेबसाइट पर प्रकाशित एक अच्छे लेख में पाई जा सकती है।

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

मान्यता

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

इंटरफ़ेस बिल्डर

क्या उल्लेखनीय है और हमारे समय की भावना में, सभी सूचीबद्ध टेक्स्ट फ़ील्ड सेटिंग्स "इंटरफ़ेस बिल्डर" में "पासवर्ड नियम" तक सेट की जा सकती हैं:

कार्यक्षमता की जाँच करें

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

उदाहरण के लिए:

 [AutoFill] Cannot show Automatic Strong Passwords for app bundleID: <...> due to error: Cannot save passwords for this app. Make sure you have set up Associated Domains for your app and AutoFill Passwords is enabled in Settings 

इसके अलावा, आपको हमेशा ध्यान रखना चाहिए कि इस प्रकार की कार्यक्षमता उन कार्यों में से है जिनके लिए उपयोगकर्ता की अनुमति आवश्यक है। इस मामले में, दो आवश्यक हैं:

1. मैं जोर से चाबी का गुच्छा;
2. ऑटोफिल।

निष्कर्ष

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

यह सुविधा काफी रोचक है और, अगर सही तरीके से उपयोग किया जाता है, तो आपके एप्लिकेशन के उपयोगकर्ता अनुभव को बेहतर बनाने में काफी सक्षम है!