VOL82: Key to our Passwordless Future - What is PassKey ?
أهلًا وسهلا بكم في العدد الثاني والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الثاني والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
PassKeys and The Future of Passwordless
Pessimistic Locking Explained
OLTP and OLAP in Database Performance at Scale
إصدارات - الإصدار الأول من مدونات فطين في تصميم النظم
PassKeys and The Future of Passwordless
الـ passkeys من التكنولوجيا اللي بتقدّم login credential أأمن بكتير من الطريقة التقليدية زي الـ username/password. والفكرة الأساسية إن الـ passkeys ماشية في طريق إنها تستبدل أغلب الـ passwords اللي إحنا متعودين عليها، بس الموضوع معتمد على تركيبة حساسة من كذا تكنولوجي، أهمهم مكوّن اسمه authenticator بأنواعه المختلفة.
ففي أي passkey workflow إنت غالبًا بتتعامل مع أربع جهات شبه مستقلة، متوصلين ببعض عن طريق standards:
الـ authenticator نفسه.
الـ website/app اللي بيتسمى relying party (السيرفر اللي بيعالج طلبات الـ login).
نظام التشغيل.
الـ web browser.
الـ authenticator هنا مش المقصود بيه بالضرورة Google Authenticator أو Microsoft Authenticator، لكن في الغالب بيكون جزء مدمج جوه أي password manager. عشان كده ناس كتير مش بتحس بوجوده كحاجة مستقلة. ومع ذلك، في authenticators تانية بتبقى stand-alone من غير ما تكون password manager.
السبب الأساسي إن الصناعة كلها بتزق ناحية passkeys هو إن إحنا كبشر أعداء لنفسنا: وتقريبًا كل يوم في breach جديدة لبيانات عملاء أو مرضى، وغالبًا البداية بتكون social engineering لموظف او حتى contractor بيسرّب login credentials بتاعة الـ corporate app.
والأبحاث بتقول إن ٩٨٪ من المستخدمين لسه بيغلطوا وبيضغطوا على scam links حتى بعد كورسات cybersecurity training. وعشان كده هنا بييجي دور الـ passkeys كأقوى دفاع متاح حاليًا.
رغم كده، معظم SaaS apps مش ماشية بسرعة كفاية في التخلص من passwords. في أنظمة الـ passkeys فيها هتستبدل username/password بالكامل، وفي أنظمة هتخلي passkeys كخيار بديل جنبهم. وفي كل الأحوال، أول ما relying parties اللي بتتعامل معاها تبدأ تدعم passkeys، مش هتقدر تتفادى إنك تعتمد على واحد أو أكتر من authenticators عشان عملية الـ login. بعكس passwords،
إنت مش هتقدر “تفتكر” الـ passkey وتكتبها بشكل يدوي؛ ولكن الـ authenticator هو اللي بيعمل كل الشغل ده أوتوماتيك.
وطبعا اختياراتك في الـ authenticator مش نهائية؛ تقدر تغيّرها بعدين. بس كل ما تمشي مسافة أطول باستخدام authenticator معيّن (أو حتى أكتر من واحد في نفس الوقت)، كل ما عملية الـ migration بعدين هتبقى أصعب وأوجع.
وجزء كبير من اللخبطة في الموضوع ده جاي من المصطلحات بتاعته. فاسم “passkey” نفسه طلع من Apple كاسم لطيف لبعض الـ Specification_، اللي هي مزيج من WebAuthn (بتاعة W3C عشان passwordless authentication على الويب) و Client-to-Authenticator Protocol (CTAP).
وكلمة authenticator في client-to-authenticator الـ client هنا غالبًا هو الـ web browser أو جزء في الـ OS مسؤول عن حركة الترافيك للويب.
من بعد ما Apple أعلنت مصطلح passkey في WWDC 2021، بقية الصناعة استخدمته، بس من ساعتها بقى فيه مصطلحات كتير وناس كتير بتتلخبط. مثال واضح: Google و Microsoft عندهم apps اسمها Authenticator.
الـ Google Authenticator شبه Symantec VIP، شغلته الأساسية توليد TOTP كـ second factor مع username/password.
والـ Microsoft Authenticator كان بيدير usernames/passwords/passkeys ويعمل autofill، لكن من يوليو ٢٠٢٥ شالوا منه username/password autofill وفضل فيه دعم لـ TOTPs ونوع محدود من passkey اسمه device-bound passkey. دلوقتي دعم autofill الشامل لـ user IDs و passwords موجود في Edge browser بدل Microsoft Authenticator.
وعندنا أكتر من نوع للـ authenticator زي: platform, virtual, و roaming.
Pessimistic Locking Explained
يعتبر الـ Locking من أهم الآليات اللي بنعتمد عليها في الـ Databases بشكل أساسي عشان نتحكم في الـ Concurrent Access للبيانات من خلال أكثر من Transactions، فلو كان هناك عدد من الـ Transactions بيحاول يوصل للبيانات دي في نفس الوقت فأكيد هيحصل نتيجة لده تضارب بنسميه Conflicts.
نقدر نتخيل الـ Locking كأنه زي القفل اللي بنقفل بيه على أي حاجة عشان نمنع أي حد من الوصول ليها. فالـ Databases أحيانًا بتحط قفل على الـ Row أو الـ Record لما يكون فيه Transaction شغال عليه عشان تمنع أي حد من الوصول للـ Row ده, اكنه دخل (الحمام وقفل وراه الباب) ..
طب هو ليه اصلا بنحتاج للـ Locking ؟
احنا بنحتاج للـ Locking لإنه بيقدملنا فوايد مهمة زي الـ Data Integrity & Data Consistency ودول من أهم الفوايد اللي بنحصل عليها من الـ Locking .. لإنه من غير Locking ممكن Two Concurrent Transactions يغيروا في قيمة الـ Column الواحد في نفس الوقت وده يسبب مشاكل كتير.
وعلى الرغم من فوايد الـ Locking الا انه بيجي مع تحديات كبيرة وتعقيدات في التعامل معاه، فلازم نكون فاهمينه عشان نقدر نتعامل معاه بشكل فعال.
فيه نوعين من الـ Locking وهم الـ Optimistic Locking والـ Pessimistic Locking بس احنا هنتكلم النهاردة عن الـ Pessimistic.
ايه هو الـ Pessimistic Locking ؟
الـ Pessimistic Locking جاي من اسمه انه شخص متشائم، بيعمل حسابه دايما على أسوء الظروف وبناء عليه بيفكر لقدام وبياخد احتياطه مسبقا.
الـ Pessimistic Locking في قواعد البيانات بيمنع الـ Conflicts الناتجة من الـ Concurrent Updates واللي بتحصل بشكل Frequent أو متكرر. فلما بنيجي نعمل عملية تحديث لـ Row أو Record معين، فالـPessimistic Locking بتحط قفل على الـRow أو الـRecord ده عشان تمنع عمليات الـ Updates التانية من انها توصل لنفس الـ Row أو الـ Record في نفس الوقت.
ممكن نتخيل أن القفل ده عبارة عن اشارة حصرية فقط لعملية الـ Update الحالية , وبالتالي مش ممكن لأي عملية تانية انها توصل لنفس البيانات اللي شغالين عليها وده لانها بتكون مقفول عليها بالقفل لحد ما العملية الحالية تنتهي.
OLTP and OLAP in Database Performance at Scale
الحمد لله ربنا كرمك وخلصت الابليكشن بتاعك وعاوز تعمله host وبقيت محتار ياترى هخلي ال SQL engine على سيرفر ومعاها ال Elastic search في نفس السيرفر ده لو اعتبرنا ان ال sql لل OLTP و ال elastic لل OLAP اللي فيها ال logs بتاع البزنسس والخ وطبعا سواء sql او elk الاتنين ينفعوا مع النوعين ال OLAP وال OLTP لكن المثال هنا للتوضيح . ولا هتخلي كل واحد في سيرفر لوحده ؟؟!
وعشان نتجاوب على السؤال ده لازم الاول نعرف ايه هم ال OLAP وال OLTP :
الـ OLTP (Online Transaction Processing) و OLAP (Online Analytical Processing) هما نوعان مختلفان من الأحمال (workloads) اللي ممكن تواجهها في قاعدة بيانات أو نظام معتمد على قواعد البيانات.
عشان نفهم الفرق بينهما، خليني أشرح بمثال عملي:
OLTP (أحمال المعاملات على الإنترنت)
ده النوع من الأحمال بيكون عادة مرتبط بالأنشطة اليومية في النظام زي المعاملات التجارية أو استعلامات المستخدمين اللي بتتم بشكل مستمر. مثلا، لو عندك قاعدة بيانات لخدمات الويب، أول ما حد يضغط على رابط أو يزور صفحة جديدة، بيحصل استعلام قاعدة بيانات عشان يتم جلب البيانات اللي تخصه بسرعة.
الخصائص:
الاستجابة السريعة مهمة جدًا، لأن المستخدمين مستنيين إجابة فورية.
بتكون فيه استعلامات بسيطة وسريعة زي عمليات قراءة وإضافة أو تحديث صغيرة.
غالبًا ما بيكون فيه أوقات تأخير منخفضة جدًا، وأي تأخير ممكن يسبب مشكلة كبيرة في تجربة المستخدم.
مثال:
تخيل إنك في موقع للتسوق على الإنترنت، ولما تضغط على منتج عشان تشوف تفاصيله، النظام بيعمل استعلام من قاعدة البيانات عشان يجيب بيانات المنتج ده ويعرضها بسرعة، ده يعتبر OLTP.
مدونات فطين في تصميم النظم - الإصدار الأول 🚀
كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.
على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:
لماذا صُمّم هذا النظام بهذه الطريقة؟
لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟
هل كان يمكن أن نصمم الأمر بشكل أبسط؟
الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.
هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.
اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.
إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.
يتناول الكتاب ما يعادل من 15 تجربة عملية مميزة من داخل الشركات العالمية في تصميم النظم الضخمة بأكتر من 160 صفحة ويضم الآتي :
Introduction Into System Design
How Uber Serves Over 40 Million Reads Per Second
How Discord Stores Trillions of Messages
Dropbox's Chrono: Scalable, Consistent and Metadata Caching Solution
Unlocking Notion's Power - The Data Model Explained
How Shopify Mitigates Deadlocks in High Concurrency Environments
How LinkedIn Improves Microservices Performance With Protobuf
How Figma Secures Internal Web Applications
How GitHub Improves Reliability of Code Push Processing
How Meta Leverages AI For Efficient Incident Response
How Stripe Architected Massive Scale Observability Solution on AWS
Change Data Capture at Pinterest
How Canva Built Scalable and Reliable Content Usage Counting Service
How Netflix Migrates Critical Traffic at Scale With No Downtime
How Slack Handles Billions of Tasks in Milliseconds
How YouTube Supports Billions of Users With MySQL
System Design Comprehensive Guide
تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇
وكمان وفرناه على Kindle عشان الناس اللي بتحب تجربة القراءة على الـ Kindle منحرمهاش من التجربة الممتعة دي 🎉
بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.
دورك كشريك أو راعي هيكون محوري في دعم المحتوى وتوسيع نطاق تأثيره. فانضم لرحلتنا وكن جزءًا من صناعة مستقبل التكنولوجيا في المنطقة 🚀
تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
