كلمات المرور التي تم إنشاؤها تلقائيًا في iOS 12

إذا كان التطبيق الخاص بك يحتوي على وظيفة تسجيل تتضمن القدرة أو الحاجة إلى إدخال اسم مستخدم وكلمة مرور جديدين ، فمن المرجح أنك ستهتم بالابتكار في نظام التشغيل iOS 12 ، الذي أود تحديده. هذه خدمة تخترع كلمات مرور جديدة للمستخدم ، وتقوم تلقائيًا باستبدالها في الحقول الضرورية وتخزينها بأمان في Keychain .

يتم إنشاء كلمات مرور النظام تلقائيًا الأكثر مقاومة للاختيار (يتم إجراء تسلسل عشوائي للأحرف - يتم ضبطه وفقًا للقيود المخصصة ، ولكن المزيد عن ذلك لاحقًا) ، يعفي مستخدمي التطبيق من الحاجة إلى الخروج بتسلسل خاص بهم ويتم تكوينهم بمرونة وفقًا لاحتياجات تطبيق معين. يتم توفير دعم الوظائف الجديدة بسهولة تامة ، ولكن ليس بدون ميزات. لكن أول الأشياء أولا.

الحقوق والواجبات

بادئ ذي بدء ، يجب أن يعلن التطبيق عن رغبته في استخدام هذه الوظيفة. في قائمة القدرات الخاصة بالهدف المطابق ، يجب أن يكون لديك أولاً مجال في قائمة المجالات المرتبطة . الغريب ، يجب أن يكون للتطبيق "مجال مرتبط" حتى يتمكن من استخدام كلمات المرور التي تم إنشاؤها وتخزينها في "سلسلة المفاتيح" للمستخدم (هاتان الوظيفتان مترابطتان ، ولا يمكن استخدام التوليد بشكل منفصل عن التخزين).

إذا كان التطبيق يدعم بالفعل استخدام الحسابات المشتركة مع موقعك (ما يسمى ب "بيانات الاعتماد المشتركة") ، فإن هذه الخطوة متأخرة بالفعل. قد يكون أيضًا متخلفًا بالفعل ، وإذا كان التطبيق يدعم الروابط العالمية أو آلية أخرى لمعالجة "عناوين URL" الخارجية.

على أي حال ، بعد إضافة هذا التوافق ، سيكون للتطبيق "استحقاق" جديد.

بالإضافة إلى هذا التوافق العام ، يجب أن يكون للتطبيق أيضًا "Capatibility" "موفر بيانات اعتماد الملء التلقائي" - وهذا يسمح للتطبيق ، إذا كان هناك إذن من المستخدم ، باستخدام تسجيلات الدخول وكلمات المرور التي يقدمها النظام. ستؤدي إضافة هذا التوافق إلى ظهور إذن " استحقاق موفر بيانات الاعتماد التلقائي" .

بالمناسبة ، تتوفر إضافة هذه الميزات وغيرها فقط لأعضاء برنامج Apple Developer .

يجب أن يشتمل ملف تعريف التوفير المستخدم من قبل التطبيق على الميزتين التاليتين.

التبعيات المستخدمة

ستؤدي إضافة التوافق المناسب إلى ظهور إطار عمل المصادقة في قائمة الأطر المرتبطة والمكتبات للهدف المقابل. هذه النقطة لديها بعض الميزات الجدير بالذكر.

أولاً ، قد لا "تعمل" الإضافة التلقائية للإطار ذي الصلة في المرة الأولى: عندما أقوم بتشغيل التطبيق على جهاز حقيقي من نسختي من الإصدار "Xcode" 10.1 ، "تعطل" التطبيق على الفور بسبب عدم وجود "AuthenticationServices". إزالة الإطار يدويا وإضافته مرة أخرى إلى قائمة المكونات ذات الصلة حل المشكلة.

ثانياً ، إضافة إطار عمل تلقائيًا يضع علامة "مطلوب". إذا كان التطبيق الخاص بك يتضمن إمكانية العمل "ضمن" "iOS" إصدارات أقل من 12 ، فسيؤدي ذلك أيضًا إلى تعطله في مرحلة بدء التشغيل "من" أنظمة التشغيل للإصدارات الأقل. "خدمات المصادقة" متوفرة فقط لأنظمة الإصدار 12. يتم حل هذه المشكلة عن طريق وضع علامة على الإطار كـ "اختياري" .

دعم مربع النص

لدعم الوظيفة مع الحقول النصية ، يتم UITextInputTraits النص المتغير textContentType لبروتوكول textContentType . UITextField فئة UITextField ، والتي تُستخدم على الأرجح لإدخال تسجيل الدخول وكلمة المرور في التطبيق ، متطلبات البروتوكول الذي نحتاجه بالفعل.

textContentType هو حقل من النوع UITextContentType يحتوي فقط على مجموعة من الثوابت. ما نحتاجه في الوقت الحالي هو newPassword ، يُستخدم لإدخال كلمة مرور جديدة يتم اختراعها في الوقت الحالي (يجب عدم الخلط بينه وبين password المستخدمة فقط لإدخال كلمة مرور موجودة).

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

يتم تعيين قيمة textContentType في فحص إمكانية الوصول إلى "واجهة برمجة التطبيقات" ، لأن هذا الثابت ، مثل الوظيفة العامة ، متاح فقط بدءًا من "iOS 12".

بالإضافة إلى نوع المحتوى ، يجب أن يوفر حقل النص إدخال بيانات آمنًا:

 passwordTextField.isSecureTextEntry = true 

على الرغم من أن التطبيق قد يوفر وظيفة عرض وإخفاء كلمة المرور المدخلة الشائعة في عصرنا ، فلن يتم تقديم كلمة المرور التي تم إنشاؤها إلا إذا كانت العلامة true في هذه اللحظة.

ترتبط نقطة مهمة بنوع محتوى حقل النص: إذا لم يكن هناك حقل آخر موجود على الشاشة ، مع username نوع المحتوى ، فلن يتم تقديم كلمة المرور التي تم إنشاؤها تلقائيًا. هذا يرجع إلى حقيقة أن الوظيفة لا تعتمد فقط على النوع المحدد لمحتوى حقل النص ، ولكن على التحليل الاستدلالي لمحتويات الشاشة .

يبدو أن إنشاء كلمة مرور "يكسر" منطق الشاشات التي تتطلب إدخال كلمة مرور جديدة مرتين للتحقق. على الأقل لم أجد حتى الآن طريقة لاستخدام هاتين الوظيفتين معًا. ويبدو أنني لست الوحيد .

تجدر الإشارة إلى أنه إذا كان تسجيل الدخول هو عنوان بريد إلكتروني بمعنى الكلمة (وبالتالي ، أريد حقًا الحصول على نوع لوحة المفاتيح المناسب) ، فيمكن دمج أنواع لوحة المفاتيح والمحتوى:

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

متطلبات كلمة المرور

غالبًا ما يجب أن تتبع كلمات مرور المستخدم قواعد معينة (لها طول معين ، وتشمل أحرفًا معينة ، وما إلى ذلك). يمكن تحديد هذه القواعد بحيث يأخذها النظام في الاعتبار عند إنشاء كلمات مرور. يتم ذلك من خلال خاصية UITextInputTraits لبروتوكول 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 مساعدًا مساعدًا لتجميع الواصف المريح ، والذي لا يوفر فقط وسيلة ملائمة لإنشائها ، بل يوفر أيضًا فحصًا للواصف المترجمة في شكل عدد غير محدود من الأمثلة التي تم إنشاؤها. هناك يمكنك أن ترى ما هي القواعد التي يتم تطبيقها بشكل افتراضي.

التحقق من الصحة

فقط في حالة ، يجب توضيح أن آلية إنشاء كلمة المرور لا توفر التحقق من صحة البيانات التي أدخلها المستخدم - تحتاج إلى العناية بهذا بنفسك. الذي ، بطبيعة الحال ، هو منطقي جدا ، ل يمكن لمستخدم التطبيق رفض كلمة المرور المقترحة تلقائيًا أو حظر إنشاء كلمات المرور والإكمال التلقائي للحقول.

باني الواجهة

ما هو جدير بالملاحظة وبروح عصرنا ، يمكن ضبط جميع إعدادات حقل النص المدرج في "Interface Builder" ، حتى "قاعدة كلمة المرور":

وظيفة التحقق

الوظيفة ليست معقدة ، ولكنها تحتوي على عدد من الفروق الدقيقة: عند تكوينها ، يمكنك بسهولة نسيان شيء ما. في هذه الحالة ، في التجميعات "debug" ، عند تنشيط حقل النص المقابل ، سيتم عرض السبب في وحدة التحكم التي لا تعمل الوظيفة بها حاليًا.

على سبيل المثال:

 [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. iCloud Keychain ؛
2. التدوين الآلي.

الخاتمة

يبدو أن هذا هو كل ما يجب الانتباه إليه أثناء توفير الدعم للوظائف الجديدة. إذا واجه شخص ما في طور العمل على ذلك ميزات أخرى مثيرة للاهتمام ، سأعلق مرة واحدة ، وإذا لزم الأمر ، تأكد من استكمال المقال.

الميزة مثيرة للاهتمام للغاية ، وإذا تم استخدامها بشكل صحيح ، فهي قادرة تمامًا على تحسين تجربة المستخدم لتطبيقك!