How can I save passwords in iCloud Keychain to use with my app and website?

بالعربي

هتكلم عن خطوه مهمه بتسهل علي مستخدمين التطبيق تسجيل الدخول وحفظ بيانات تسجيل دخولهم

ايه هي؟ هي اننا بنخلي السيستم يسال المستخدم حابب يحفظ ال username وال password في ال passwords عنده ولا لا

طيب ليه؟ لإنه ع الأغلب المستخدم وارد يبقي ليه اكتر من حساب ووارد ينسي اصلا هو كان مسجل بإيه فده اوبشن بيسهل عليه انه يفتكر ايه الحسابات اللي عملها للتطبيق بتاعك والباسورد بتاعها وكمان بتبقي shared بين كل أجهزته اللي ليها نفس ال apple ID، ووارد كمان يبقي التطبيق موجود iOS و web وانت حابب ان ال password تكون shared

طيب مش انا ممكن اخزن بيانات المستخدم عندي جوا الابلكيشن بشكل آمن؟

اه طبعا ممكن لو استخدمت ال keyChain وده هيكلفني تأمين بيانات المستخدم عندي وازاي احفظها وازاي استخدمها وطبعا مش هيديني المميزات اللي فوق

نبدأ بقي موضوعنا..

احنا عندنا خطوتين عشان نقدر نشغل ال Feature دي

١- هنفعل ال associated domains

٢- هنعمل set لل content type لكل text field في ال Forms المختلفه عندي (مهم جداً)

بس كده؟؟ اه بس كده تخيل!!

دول باختصار ونبدأ بأول خطوه وهي

اول خطوة: تفعيل ال associated domains

إيه هي وبتعمل إيه؟ ببساطة، زي ما اسمها بيقول، Associated Domains بتربط التطبيق بتاعك مع الويبسايت المرتبط بيه. يعني لو التطبيق اللي شغال عليه ليه ويبسايت، والمستخدم سجل دخول على الموقع باستخدام بيانات معينة، التطبيق بتاعك يقدر يستخدم نفس بيانات تسجيل الدخول دي عشان يعمل تسجيل دخول لنفس المستخدم.

طيب لو معنديش ويبسايت، كده مش هحتاجها؟
لا، هتحتاجها برضه! لأن دي خطوة مهمة عشان iCloud Keychain يعرض على المستخدم خيار إنه يحفظ الـ username وpassword اللي استخدمهم للتسجيل في التطبيق.

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

لو ما فعلتش Associated Domains في التطبيق بتاعك، النظام مش هيعرض على المستخدم يحتفظ ببيانات التسجيل دي.

وكمان، في نقطة مهمة وهي الأمان (security). Associated Domains بتضمن إن عملية مشاركة البيانات، زي تسجيل الدخول، بتحصل بطريقة آمنة. الفايل اللي هنرفعه كمان شويه (اللي هو apple-app-site-association) بيأكد للنظام إن النطاق (الدومين) اللي بتتعامل معاه موثوق وآمن.

حاجه تانية بتعملها ال cabapility دي هي خاصية ال Autofill واللي بيها بتكتب للمستخدم بياناته في ال textfields حسب كل نوع سواء username فهتملاه بال username او password او code او اقتراح ل new password

طيب نضيف بقي ازاي ال cabapilty دي؟ باننا نعمل الخطوات اللي في الصوره تحت

احنا كده ضفنا ال cabapility جوا البروجكت بتاعنا وبعد ما بنضيفها

بنلاقي section لل associated domain عشان نضيف فيه ال domain المرتبطه بالتطبيق بتاعي فندوس علي +

هيتضفلنا example للدومين فنعدله وهنا ناخد بالنا من حاجه

• لما تيجي تضيف Associated Domains في التطبيق بتاعك، لازم تستخدم شوية prefixes (يعني كلمات بتحطها قبل الدومين) عشان تقول للنظام انت ناوي تربط إيه ما بين التطبيق بتاعك والموقع. كل prefix له وظيفة معينة، ودول أشهرهم:

  ١- applinks:

  ده لو انت عايز تخلي الروابط (اللينكات) اللي بتخص موقعك تفتح التطبيق بدل ما تفتح في المتصفح. يعني لو حد ضغط على لينك يخص موقعك وهي عنده التطبيق، التطبيق يفتح على طول.

  مثال: applinks:yourdomain.com

  ٢- webcredentials:

  ده لو عايز تخلي التطبيق بتاعك يستخدم ميزة AutoFill لحفظ اسم المستخدم والباسورد في iCloud Keychain. كده لو المستخدم سجل دخول في موقعك من على المتصفح، التطبيق يعرف يستخدم نفس البيانات دي.

  مثال: webcredentials:yourdomain.com

  ٣- appclips:

  ده لما يكون عندك App Clips، اللي هي نسخة صغيرة من التطبيق بتفتح جزء معين منه بدون ما يضطر المستخدم ينزل التطبيق كله.

  مثال: appclips:yourdomain.com

  ٤- activitycontinuation:

  ده لو عايز تدعم ميزة الـ Handoff، يعني المستخدم لو كان شغال على حاجة في تطبيقك على جهاز، يقدر يكملها على جهاز تاني زي الآيباد أو الماك.

  مثال: activitycontinuation:yourdomain.com

طيب احنا كده قلنا للتطبيق هو مرتبط بمين، المفروض نقول برضه للويبسايت انه مرتبط بالتطبيق وده بيحصل عن طريق فايل اسمه apple-app-site-association

طيب ايه هو الفايل ده؟

من اسمه باين انه عباره عن ربط بين التطبيق بتاعنا والويبسايت، الفايل ده هو json file عادي بس من غير اي extension يعني مبيبقاش apple-app-site-association.json لا ، لاااازم بدون extension وبيتحط في ال root بتاع ال domain بتاعنا https://yourwebsite.com/apple-app-site-association

او في ال .well-known directory ويبقي بالشكل ده https://yourwebsite.com/.well-known/apple-app-site-association

طيب ال json بقي عباره عن ايه؟

فاكر ال prefixes اللي فوق؟ نفسهم هيبقي ف الفايل ده مع شوية معلومات تانيه ولو عاوز تشوف شكله ممكن تشوف facebook: https://facebook.com/apple-app-site-association

بس ف حالتنا احنا محتاجين نعرف بس بنضيف ايه لل webcredentials

وده اللي بنضيفه للفايل ونبعته للباك اند يضيفوه في ال root للدومين وزي ما باين ان ال app هي array فاقدر اضيف كذا تطبيق بكذا team id عادي

وبكده السيستم هيعرض لل domains دي بس ال credentials اللي كنت مسجلها من خلال التطبيق والعكس

---

تاني خطوة: نعمل set لل content type لكل text field في ال Forms المختلفه عندي

مبدأيا في حاجتين لازم نخلي بالنا منهم وهما:

• ان ال text fields اللي بناخد منها بيانات التسجيل او بنملي فيها لازم تكون ظاهره ف السكرين حتي لو بارتفاع 0 عشان ال autofill algorith يقدر يشتغل وتكون واخده content type صح

• ان الfields تكون بالترتيب الصح عشان ال algorithm يقدر ي collect او ي set ال credentials صح

طيب هو ال autofill بيشتغل ازاي(اللي هو جزء من ال associated domains)

• لازم الاول اكون بكتب جوا textfield ليه content type من ال types اللي هو بيستخدمها زي ال username و password

• ال autofill بيقول ان هنا فيه سيناريو من السيناريوهات بتاعتي سواء login او registration او حاجه تانيه

• بعدين بيتأكد هل في ربط بين التطبيق وبين ال associated domain لو مفيش مبيعملش اي اكشن ومش بي offer انه يعمل save

• اتاكد ان في ربط، بيبدأ يشوف فين ال fields فمثلا لو لقي fields واحد username والتاني password هيعرف ان ف لوجن فورم وهيقترح بيانات مستخدم لو كان متسجل قبل كده بيانات او هي collect منهم البيانات عشان يعمل save

• بعدين بيعرف ان الاكشن الخاص بالاسكرين حصل زي مثلا ان اتعمل لوجن او register، وبيعرف ده بان ال fields تتشال من ال hierarchy باني اروح لسكرين تانيه مثلا او اعمل pop او dismiss للسكرين الحاليه

• بعدين بيقترح بقي علي المستخدم سواء حفظ الباسورد او انه يعمل update لباسورد موجود بالفعل

طيب نتكلم بقي عن الترتيب

١- ال Login Screen

علشان الـ AutoFill يشتغل صح، الـ username بيكون في الأول وبعده ف الترتيب في ال UI بيكون الباسورد، وده بناءً على ترتيب الـ Content Type اللي بتحددها لكل Text Field في الـ Form:

• اليوزرنيم: لازم يكون الـ Content Type بتاعه username.

• الباسورد: لازم يكون الـ Content Type بتاعه password.

دول اللي محتجاهم فيها عشان ال autofill يقدر يعرف انها login screen

بمجرد ما بدوس علي ال textfield وبيبقي firstresponder بيظهرلي ال keyboard وفي ال Quicktype bar هلاقي Passwords لاني مسجلتش لسه اي credentials زي اول صوره بس لو فيه متسجل هتظهرلي بالشكل ف تاني صوره

٢- ال Registration Screen

• في حالة الـ Register Form، الـ iOS بيدعم نفس الترتيب اللي بيطلبه في Login Form علشان يقدر يتعرف على ال fields ويخزن البيانات بشكل صحيح . الترتيب اللي لازم تلتزم بيه هو:

  1. الusername (أو الإيميل) يكون الأول:

     لازم الـ Text Field بتاع اليوزرنيم أو الإيميل يبقى Content Type بتاعه هو username أو emailAddress على حسب اللي هتستخدمه.

  2. الباسورد يكون بعده:

     الـ Text Field بتاع الباسورد لازم يكون الـ Content Type بتاعه newPassword في حالة الـ Register علشان الـ iOS يفهم إن ده باسورد جديد بيتعمل.

  3. تأكيد الباسورد (اختياري):

     لو فيه field لتأكيد الباسورد (Confirm Password)، الـ Content Type بتاعه ممكن يكون newPassword برضه، بس مش إجباري تضيفه.

• الفرق بينها وبين اللوجن ان ال autofill بيقترح للمستخدم ايميلات او username هو بيستخدمهم ف العادة

• وعشان يقدر يميز ان دي registration لازم يكون فيه ال newpassword دي اهم حاجه عشان يميز انها registeration

• بمجرد ما المستخدم يدوس علي ال username field هيقترحله ايميل او username في ال Quicktype bar وبمجرد ما يدوس علي الباسورد هيقترحله strong password

• بعد ما يتم الاكشن واللي هو بيعتبره حصل بمجرد ان الfields متبقاش في ال hierarchy بيعرض عليه ي save password

٣- Change password

هنا لازم الترتيب ولازم ال username يكون موجود وظاهر مش hidden ويكون بين ال oldPassword وال newPassword عشان ال autofill يقدر يتعرف علي ال form وينفذ ال algorithm ويقدر يعرف هو هيعمل update لمين ولو مش عاوزه موجود فانت ممكن تصغره انما متقدرش تشيله خالص

شوية ملحوظات وقفت معايا!!!!!!

• لو بعمل لوجين ب email او mobile مينفعش يبقي في اتنين fields ليهم content type يبقي username ال autofill هيعطل ومش هيعمل حاجه فلو في switch بينهم شيل خالص ال field من ال view وخلي واحد بس

• السيستم بيسجل ايميل وusername فلو الاتنين موجودين ك content type ف السكرين هو هيشتغل بمزاجه وده ممكن يسببلك حاجات مش متوقعه فحدد ال content type ف ال form بتاعتك لل fields بس اللي عاوزه ياخد منها الداتا او يعمل فيها set

• لو فكرت تجرب ترتيب ال change password فانا جربت وبقولك منفعتش فعلا الا لو عندك workarounds

• و بتستخدم pod عشان ال country code في اللوجين متنساش انك بتحتاجه عشان تحتفظ بال credentials صح فانا عملت workaround باني خليت في textfield ارتفاعه صفر بعمل فيه set للرقم والكود مع بعض عشان لما اخرج م السكرين يقرا الداتا بشكل سليم ويعمل لوجين بشكل سليم