VOL72: How Card Payments Secured With 3DS
أهلًا وسهلا بكم في العدد الثاني والسبعين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الثاني والسبعين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
3DS Challenges in Online Payments
Change Data Capture at Pinterest
Critical Rendering Path
Sessions vs Cookies
الإصدار الأول من مدونات فطين في تصميم النظم
3DS Challenges in Online Payments
لو سبق لك الدفع ببطاقتك البنكية عبر الإنترنت، فغالبًا قابلت خطوة بيظهر فيها طلب إدخال رمز OTP المرسل من البنك لتأكيد العملية. هذه الخطوة تُعرف باسم 3DS Challenge، وهي واحدة من أهم الإجراءات الأمنية في عمليات الدفع الإلكتروني.
أهمية 3DS Challenge
الغرض الأساسي من هذه الخطوة:
تقليل عمليات الاحتيال: عبر التحقق الإضافي من هوية حامل البطاقة.
نقل مسؤولية المخاطرة: من التاجر (Acquirer) إلى البنك مصدر البطاقة (Issuer) في حالة حدوث نزاع على العملية. وهذه النقطة تُعرف باسم Liability Shift.
ما معني Liability Shift؟
ببساطة: إذا اعترض العميل على عملية دفع وادعى أنها احتيالية، وتم التحقق منها بنجاح عبر 3DS Challenge، فإن البنك مصدر البطاقة هو من يتحمل المسؤولية، وليس التاجر.
لماذا يُسمى 3DS؟
كلمة 3DS اختصار لـ 3 Domain Secure، وهو يشير إلى ثلاث جهات رئيسية تشارك في العملية:
بنك التاجر (Acquirer Domain)
شبكة البطاقة (Card Network Domain)
البنك مصدر البطاقة (Issuer Domain)
خطوات عمل 3DS Challenge
العملية تمر بعدة مراحل، وغالبًا تحدث قبل خطوة الدفع الفعلية:
3DS Lookup
بوابة الدفع تتواصل مع Directory Server (DS) الخاص بشبكة البطاقة (Visa / Mastercard) للتحقق من دعم البطاقة لخدمة 3DS .
إذا كانت البطاقة مدعومة، يحدد الخادم ACS (Access Control Server) الخاص بالبنك، وهو الخادم الذي يعرض صفحة إدخال رمز OTP، ويكون تحت إدارة البنك مباشرة.
إرسال طلب التحقق (AReq)
إذا كانت البطاقة تدعم 3DS، تقوم بوابة الدفع بإرسال Authentication Request (AReq) إلى خادم التحقق (ACS).
يحتوي هذا الطلب على بيانات مهمة مثل: رقم البطاقة، عنوان IP، بيانات المتصفح، والمبلغ.
التحقق من العميل
هنا يقرر البنك كيفية متابعة العملية:
Frictionless Flow: إذا اعتبر البنك العملية آمنة، يتم إتمام التحقق دون عرض أي صفحة للعميل.
Challenge Flow: إذا كانت هناك حاجة للتحقق الإضافي، يعرض البنك صفحة OTP ليدخل العميل الرمز.
استلام النتيجة (ARes)
يرسل البنك نتيجة التحقق عبر Authentication Response (ARes)، والتي تحتوي على:
قيمة اسمها CAVV = Cardholder Authentication Verification Value ودي بينشأها البنك مصدر البطاقة بعد التحقق من العملية.
ال ID الخاص بعملية التحقق في ال ACS Server الخاص بالبنك
حالة التحقق (transactionStatus) وبيكون حرف بيمثل نتيجة العملية: Y ناجح، N: فشل، U: غير متاح
ECI (Electronic Commerce Indicator):رقم يحدد نوع العملية وهل حصل فيها تحقق 3DS ام لا. القيم 02 او 05 تعبر ان التحقق تم بشكل سليم.كمان انه يستخدم من قبل شركات البطاقات لتحديد مسؤولية العملية في حالة حدوث Chargeback.
من النقاط المهمة جدا والتي يعتمد عليها تطبيقات كثيرة هي ان البيانات الخاصة بعملية التحقق تكون ناتجة من بنك مصدر البطاقة، فبغض النظر عن بوابة الدفع التي تقوم بارسال البيانات للبنك، سيتمكن البنك من التعرف عليها. ومن ضمن العمليات المعتمدة علي هذه النقطة:
التحقق مع بوابة دفع واستخدم البيانات مع بوابة دفع اخري لاستكمال عملية الدفع.
تكرار المحاولة لو العملية فشلت العملية بسبب خطأ أو رفض من بوابة الدفع، سواء من نفس البوابة أو باستخدام بوابة اخري.
نصيحة للمبرمجين
عرض صفحة 3DS Challenge بشكل يحافظ على تجربة المستخدم؟
هنا بيكون قدامك اختيارين:
Change Data Capture at Pinterest
في عالم النهاردة واللي بيعتمد على البيانات بشكل كبير، الشركات محتاجة تعالج وتحلل البيانات بشكل لحظي عشان تاخد قرارات صح. وتقنية الـ Change Data Capture (CDC) ظهرت كحل سحري واعتمدت عليها Pinterest في قواعد بياناتها .
الـ CDC بتساعد المؤسسات إنها تتابع وتلتقط التغييرات اللي بتحصل في قواعد البيانات بتاعتها بكفاءة وعشان كده في المقال ده، هنكتشف يعني إيه CDC، وليه هي مهمة، وإزاي Pinterest قدروا يطبقوا حلول الـ CDC بشكل عام لكل قواعد البيانات بتاعتهم.
يعني إيه Change Data Capture؟
الـ CDC عبارة عن مجموعة من أنماط التصميم اللي بتستخدم لتحديد وتتبع التغييرات في قاعدة البيانات، زي الإضافات (inserts)، والتحديثات (updates)، وعمليات الحذف (deletes).
التقنية دي بتسمح للتطبيقات إنها تستجيب للتغييرات دي في وقت لحظي Realtime، وده بيخليها جزء أساسي في تكامل البيانات (Data Integration)، وكذلك في الـ (replication)، وعملية المزامنة الخاصة بقواعد البيانات وبعضها.
ليه الـ CDC مهمة؟
معالجة البيانات بشكل لحظي (Realtime): الـ CDC بتمكّننا من معالجة البيانات لحظة بلحظة عن طريق انها بتلتقط التغييرات أول بأول. وده مهم للتطبيقات اللي بتحتاج معلومات محدثة الـ
Fraud Detection Systemsأو الـRecommendation Engines.تكامل البيانات (Data Integration): من خلال التقاط التغييرات أول بأول، الـ CDC بتسهّل تكامل البيانات بين أنظمة مختلفة. وده مفيد في البيئات اللي فيها تطبيقات متعددة بتحتاج توصل لنفس البيانات وتعالجها وممكن تكون ليها قواعد بيانات مختلفة ولكن هي محتاجة نفس البيانات.
تقليل الحمل على الـ Source Systems: بدل ما نعمل تحميل كامل للبيانات ونعملها كلها Loading وبعدين ننقلها كلها .. فالـ CDC بتسحب التغييرات اللي حصلت، وده بيقلل الحمل على الأنظمة المصدرية وبيحسّن الأداء.
الـ Audit & Compliance: الـ CDC بتوفر طريقة موثوقة لتتبع التغييرات اللي حصلت وده مناسب جدًا للـ Auditing والـ Compliance، فبتضمن إن كل التعديلات متسجلة وقابلة للتتبع.
رحلة Pinterest في تنفيذ الـ CDC
خلونا دلوقتي نشوف رحلة Pinterest وازاي قدروا يطبقوا وينفذوا الـ CDC في قواعد البيانات بتاعتهم وإنهم يبنوا حاجة Generic تتماشى مع الـ System بتاعهم ونشوف ايه التحديات اللي قابلوها واتصرفوا معاها ازاي.
تحديات الـ CDC السابقة
في الماضي، فرق مختلفة في Pinterest نفذت حلول CDC منفصلة عشان يلبوا احتياجات محددة خاصة بيهم. ورغم إنها كانت فعّالة لغرضها، إلا إن الحلول دي سببت عدم رضا للمستخدمين بسبب التباينات اللي ظهرت، وعدم وضوح المسؤوليات مين مسئول عن ايه، ومشاكل من ناحية الموثوقية أو الـ Reliability.
بناء Generic CDC
عشان فريق Pinterest يحل التحديات دي، قرروا إنهم يبنوا حل CDC Generic ويكون معتمد على Debezium™ من Red Hat. الحل ده بيهدف إلى:
ضمان أنظمة موثوقة (Reliable)، بزمن استجابة منخفض يعني Low-Latency، وتكون قابلة للتوسع Scalable، مع ضمان معالجة البيانات على الأقل مرة واحدة وده اللي بنسميه At Least Once Processing.
دعم الـ Distributed Databases بشكل كبير.
تنفيذ Load Balancing قوي وتقليل التأثير على قواعد البيانات الأساسية.
توفير إمكانيات للـ Configuration والـ Observability متقدمة للمستخدمين.
Pinterest CDC Architecture
البنية التحتية لقواعد البيانات في Pinterest بتتميز بالتوزيع العالي Highly Distribution، وكل وحدة موزعة بنسميها shard. بعض قواعد البيانات الكبيرة ممكن يكون فيها حوالي 10,000 shard. وعلى الرغم من إن Debezium Connector المفتوح المصدر، زي MySQL Connector، بيشتغل بشكل سلس مع shard واحدة فقط.
فالتحدي كان في توافقه مع قواعد البيانات الموزعة بتاعة Pinterest خصوصًا إن هم عندهم Distributed Architecture.
Critical Rendering Path
في المقال الي فات والي ممكن نشوفه من هنا اتكلمنا عن رحلة ال user من أول ما بيكتب اسم موقع أو يضغط علي رابط معين لحد ما ال browser بيستلم أول byte من السيرفر، وفي المقال دا هنتكلم عن إزاي المتصفح بيبدأ يفهم ال bytes اللي جايه من السيرفر لحد ما يحولها لموقع interactive متكامل يقدر يتفاعل معاه، ودا بيتم عن طريق بعض الخطوات تسمى ب ال Critical reading path .
Critical reading path
ال critical rendering path عبارة عن خطوات بيتبعها المتصفح علشان يحول ال bytes اللي بيستلمها من ال server ل pixels بتظهر ل ال user علي الشاشة يقدر يتفاعل معاها، والخطوات دي بتتمثل في الآتي .
Dom construction
Cssom construction
Rendering
Dom construction
أول ما المتصفح ما بيستلم أول جزء من البيانات من السيرفر واللي بتكون عبارة عن مجموعة bytes متمثلة في ملف ال HTML، بيبدأ يحلل البيانات دي (يعملها parsing) ويوصل في النهايه ل Dom object model ودا بيتم عن طريق بعض الخطوات .
التحويل من Bytes لـ Characters المتصفح بيقرأ الـ HTML كـ Bytes من ال Server وبيحوّلهم لحروف بناءً على نوع التشفير (زي UTF-8) مثلا .
Tokenizing (التقطيع) المتصفح بيقسم الحروف دي لرموز بتسمي (tokens) زي <html>, <body>.
Lexing (تحويل الرموز ل objects) الرموز دي بتتحوّل ل (Objects) بتوضح خصائصها وقواعدها وال attributes وال methods الي بتحتويها .
بناء شجرة الـ DOM وربط العناصر ببعضها .اخيرا بيبدأ المتصفح بيربط ال objects دي على شكل شجرة فيها علاقات "أب وابن" يعني <html> هو الأب الخاص ل ال <body> وهكذا .
Preload Scanner
في الوقت الي بيكون في المتصفح بيبني ال DOM بيكون ال Preload Scanner عمل scan ل ملف HTML وبيعمل fetch لكل ال resource الموجود زي ملفات CSS أو JavaScript وال images أو الخطوط قبل ما ال browser يوصلها أثناء عملية ال parsing.
ليه ال Preload Scanner مهم ؟
Sessions vs Cookies
في الـ Web Development فيه مشكلة بتقابلنا الا وهي ان الـ HTTP بطبعه بيكون Stateless يعني مش بيحتفظ بأي بيانات , وعشان نعالج المشكلة دي ونخلي فيه State موجودة نقدر من خلالها ندير البيانات ونخزنها , ظهر الـ Cookies والـ Sessions
فهما أدوات أساسية لإدارة البيانات وتخزينها أثناء تفاعل المستخدمين مع المواقع, بالرغم من تشابههم في بعض الجوانب، إلا أن كل واحد منهم ليه استخدامات وخصائص مميزة. هنشرح بالتفصيل الفرق بينهم وامتى بنستخدم كل واحد فيهم
الـ Cookies
الـ Cookie هي ملف نصي صغير بيتم تخزينه في جهاز المستخدم (زي الكمبيوتر أو الموبايل) بواسطة المتصفح. الهدف الرئيسي من الـ Cookie هو تخزين معلومات بسيطة بتساعد الموقع في تذكر المستخدم والتفضيلات بتاعته.
استخدامات الـ Cookies
الـ Cookies ليها استعمالات كتير من ضمنهم:
تسجيل الدخول: المواقع بتستخدم الـ Cookies علشان تفتكر المستخدمين المسجلين وتوفر عليهم عناء تسجيل الدخول كل مرة.
تتبع النشاط: المواقع بتستخدم الـ Cookies لتتبع سلوك المستخدمين وتحليل نشاطهم لتحسين الخدمات والإعلانات.
تخصيص المحتوى: بتساعد الـ Cookies في تخصيص تجربة المستخدم عن طريق تذكر تفضيلاته، زي اللغة المفضلة أو ثيم الموقع.
مدة تخزين الـ Cookie
فيه نوعين من الـ Cookies الا وهم الـ Session Cookie والـ Persistent Cookie وكل واحد فيهم بتختلف مدة تخزينه عن التاني:
Session Cookies: بتنتهي بمجرد ما المستخدم يقفل المتصفح.
Persistent Cookies: بتفضل موجودة لفترة محددة بيحددها المطور، وبتنتهي أوتوماتيك بعد المدة دي.
خصم 50% على جميع خطط الاشتراك السنوية لفترة محدودة، تقدروا دلوقتي تشتركوا في اقرأ-تِك وتستمتعوا بكافة المقالات في كل ما يخص هندسة البرمجيات باللغة العربية والمحتوى المميز من ورقة وقلم ومدونات فطين اللي بيتميزوا بتصاميم ذات جودة عالية وكل ده بحرية كاملة وكمان مفاجآت اقرأ-تِك الجاية 🚀
وبرضو متاح الاشتراك من خلال InstaPay و VodafoneCash 🎁
مدونات فطين في تصميم النظم - الإصدار الأول 🚀
كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.
على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:
لماذا صُمّم هذا النظام بهذه الطريقة؟
لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟
هل كان يمكن أن نصمم الأمر بشكل أبسط؟
الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.
هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.
اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.
إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.
يتناول الكتاب ما يعادل من 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 بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
