🔐 الفرق بين Hashing و Encryption و Salting و Pepper
.
.
الأربع مصطلحات قريبين من بعض في إن كلهم ليهم علاقة بتأمين الـ data. بس الحقيقة إن كل واحد فيهم ليه هدف مختلف تمامًا وطريقة استخدام مختلفة، ولو خلطت بينهم أو استعملت حاجة مكان التانية هتعمل مشكلة كبيرة في السيستم بتاعك.

تخيل معايا إنك بتعمل منصة فيها مستخدمين بيسجلوا بالإيميل والباسورد. طبيعي إنك لازم تخزن الباسورد بشكل آمن، صح؟ هنا بقى السؤال:

- هل أخزن الباسورد زي ما هو plain text؟
- طب هل أعمله Encryption؟
- ولا Hashing كفاية؟
- طب إيه لازمة الـ Salt؟ وإيه الفرق بينها وبين الـ Pepper؟

———

🟢 الـ Hashing

الـ Hashing هو إنك بتحول الـ data (زي الباسورد) لسلسلة من الأرقام والحروف ملهاش معنى.
الميزة الأساسية: ده one-way، يعني تقدر تحول الباسورد لـ hash، لكن مستحيل ترجع من الـ hash للباسورد.

📌 الهدف: تستخدمه عشان تتحقق من البيانات، مش عشان تسترجعها.
مثال: المستخدم يدخل الباسورد، وأنت تعمله hash بنفس الـ algorithm وتقارن مع اللي مخزنه.

❌ المشكلة: لو اتنين مستخدمين عندهم نفس الباسورد، الـ hash بتاعهم هيبقى نفس النتيجة. وده بيخلي الموضوع عرضة لهجمات زي الـ Rainbow Tables.

———

🔵 الـ Encryption

الـ Encryption مختلف تمامًا. هنا بتعمل عملية reversible (يعني ينفع ترجع للبيانات الأصلية).
تخزن الـ data مشفرة، وتقدر تفكها بالـ key.

📌 الهدف: حماية البيانات اللي لازم تسترجعها زي الرسائل، الملفات، بيانات الكريدت كارد… إلخ.
مثال: تشفير رسالة في واتساب، المستقبل يقدر يفكها بالـ key والرسالة الأصلية ترجع.

❌ المشكلة: لو الـ key اتسرب، كل حاجة مكشوفة.

———

🟡 الـ Salting

الـ Salt هو string عشوائي بتضيفه للباسورد قبل ما تعمله hash.
ليه؟ عشان تمنع الهجمات اللي بتعتمد على إن نفس الباسورد عنده نفس الـ hash.

📌 الهدف: تعمل كل hash مختلف حتى لو كلمات السر متشابهة.

مثال:
- مستخدم1 = "123456" + SaltA → hash1
- مستخدم2 = "123456" + SaltB → hash2

رغم إن الباسورد هو نفسه، لكن الـ hash مختلف.

———

🔴 الـ Pepper

الـ Pepper شبه الـ Salt لكن في نقطة مختلفة: بيكون secret value بتضيفه للباسورد قبل الـ hashing.
بعكس الـ Salt اللي ممكن يتخزن مع الـ hash، الـ Pepper مش بيتخزن في الداتابيز، بيتخزن في config آمن أو environment variable.

📌 الهدف: تضيف طبقة حماية إضافية ضد أي حد يسرق الداتابيز. حتى لو معاه الـ hashes + salts، لسه ناقصه الـ pepper.

———

كلمات السر لازم تتحفظ بالـ Hashing + Salt + Pepper، مش بالـ Encryption.

الـ Encryption مكانه في البيانات اللي لازم تسترجعها زي الرسائل أو الملفات.

———

وفقكم الله لكل خير 🌿

🔰 JavaScript DOM Selection and Manipulation

دردشة سريعة عن الـ OAuth 2.0 💡
.
.
تخيل إنك داخل تسجّل في تطبيق جديد علشان تتابع كورسات، ولما جيت تسجّل، التطبيق قالك:
"تقدر تسجّل بحساب Google أو GitHub بدل ما تعمل أكونت جديد"

ضغطت على زرار "Continue with Google"، وGoogle طلبت منك تختار الإيميل وتوافق على شوية صلاحيات.
بعدها التطبيق فتح واشتغل وكأنك عملت sign up فعلًا...

إيه اللي حصل هنا؟ 🤔
اللي حصل بالضبط هو إن Google استخدمت حاجة اسمها OAuth 2.0.

———

📌 يعني إيه OAuth 2.0؟

ببساطة، الـ OAuth 2.0 هو بروتوكول authorization (مش authentication)، بيخلّي التطبيقات تقدر تاخد إذن من المستخدم عشان تدخل على جزء من معلوماته في service تانية (زي Google, Facebook, GitHub) من غير ما يعرفوا الباسورد بتاعتك.

يعني التطبيق اللي بتستخدمه مش بيشوف الباسورد بتاعتك، بس بياخد توكن مؤقت يقدر يستخدمه يدخل على الـ APIs اللي أنت وافقت عليها.

وده بيخلي العملية آمنة، وبيحافظ على الخصوصية بتاعتك.

———

📌 إزاي الـ OAuth 2.0 بيشتغل؟

تعال نمشي خطوة بخطوة في الـ flow المشهور بتاع Authorization Code Grant Flow، واللي بيستخدم في web apps

1- الـ User Requests Login
التطبيق (Client) يقولك: "سجّل بحساب Google مثلًا"، والمستخدم يضغط على الزرار، ويتم توجيهه على authorization server (زي Google).


2- الـ User Grants Permission
جوجل يطلب منك تسجّل دخول وتوافق على الـ permissions اللي التطبيق طالبها (زي الإيميل، الاسم، إلخ).


3- الـ Authorization Code
لو وافقت، Google هيبعت authorization code للتطبيق (أو تحديدًا للـ redirect URL اللي التطبيق حدده قبل كده).


4- الـ Token Exchange
التطبيق ياخد الـ authorization code ده ويبعت request لـ token endpoint علشان يبدله بـ access token (وساعات كمان refresh token).


5- الـ Access Protected APIs
بمجرد ما التطبيق ياخد الـ access token، يقدر يستخدمه يطلب بيانات من Google APIs، بس في حدود الـ scope اللي وافقت عليه.

———

إزاي بيأمن الـ APIs؟ 🔐

لو عندك API وعايز تأمنها، ممكن تستخدم OAuth 2.0 بحيث:

- أي Client مش هيقدر يوصل لـ API غير لما يقدّم Access Token صالح.
- الـ Backend بتاعك يقدر يتحقّق من التوكن (مثلًا JWT أو عن طريق introspection endpoint).
- تقدر تتحكّم في الصلاحيات عن طريق الـ scope (يعني مثلًا توكن معين يقدر يقرأ بس، وتوكن تاني يقدر يكتب ويعدّل).
- تقدر تسحب صلاحيات التوكن في أي وقت (Revoke).


بالتالي، OAuth 2.0 بيأمّن الـ APIs عن طريق إنه:

✅ بيقلل الاعتماد على كلمات المرور
✅ بيسمح بالـ delegation (تطبيق ياخد إذن من مستخدم يوصل لحاجة مش بتاعته)
✅ بيخلي الـ tokens مؤقتة، وممكن تتحكم في صلاحياتها ومدّتها

———

📌 أنواع الـGrant Types المشهورة:

- الـ Authorization Code (with PKCE): للموبايل والويب.
- الـ Client Credentials: للـ machine-to-machine apps.
- الـ Password (deprecated): كان بيستخدم لما المستخدم يكتب الـ username والباسورد في نفس التطبيق (غير آمن).
- الـ Implicit (deprecated): زمان كان بيتستخدم للـ SPA apps لكنه غير موصى به.

———

لو كنت بتستخدم OAuth 2.0 في موبايل أو SPA app، لازم تستخدم حاجة اسمها PKCE (Proof Key for Code Exchange) علشان تمنع الـ authorization code من إنه يتسرق.

———

وفقكم الله لكل خير 🌿

دردشة سريعة عن الـ RFC 💡
.
.
في أوقات كتير بيكون عندك فكرة حلوة — ممكن تكون تحسين في الأداء، refactor، أو feature جديدة —
بس أول ما تحاول تشرحها للتيم، الحوار بيبقى عشوائي، والناس بتفهم نص الفكرة أو ترفضها قبل ما تستوعبها أصلًا...

علشان كده التيمات في الشركات الكبيرة والمتوسطة بتستخدم حاجة اسمها RFC – Request For Comments،
ودي ببساطة طريقة منظمة بتخليك تشرح فكرتك بالتفصيل، وتخلي الكل يشارك رأيه قبل التنفيذ.

———

📌 يعني إيه RFC؟

الـ RFC عبارة عن مستند مكتوب بيشرح فيه صاحب الفكرة كل حاجة عن الـ feature أو التغيير اللي عايز يعمله:
من الـ context، والـ problem اللي بيحاول يحلها، لحد الـ proposed solution، والـ alternatives، والـ trade-offs.

الهدف إنك تشارك التفكير بتاعك مع التيم علشان الكل يقدر يناقش الفكرة من وجهات نظر مختلفة — هندسية، product، أو حتى business.

———

🎯 ليه مهم نكتب RFC؟

فيه 3 أسباب رئيسية بتخلي الـ RFCs مهمة جدًا في أي تيم:

1- بتمنع القرارات الفردية العشوائية:
بدل ما أي حد يغيّر في الـ codebase أو الـ system architecture بمزاجه، الـ RFC بتخلي القرار جماعي ومدروس.

2- بتوثّق القرارات التقنية:
بعد 6 شهور لما حد يسأل “ليه اخترنا نستخدم Redis هنا؟”، تقدر ترجع لـ RFC وتشوف reasoning واضح بدل ما تعتمد على الذاكرة.

3- بتحسّن التعاون بين الفرق:
الـ frontend، backend، DevOps... الكل بيبقى عارف الاتجاه العام للـ system وبيشارك في القرار.

———

إزاي تكتب RFC محترم؟ 🤔

الـ structure مش ثابت، بس فيه فورمات متعارف عليه وبيخلي الـ RFC واضح ومنطقي.

📍 الـ Title + Summary
ابدأ بعنوان بسيط وواضح يشرح هدف الـ RFC.

مثلًا:

RFC: Introduce caching layer for product API

وبعدها اعمل Summary صغير بيشرح في جملة أو اتنين الفكرة العامة:

We propose adding a Redis-based caching layer to reduce response time for frequently accessed endpoints.

📍 الـ Context / Background
احكي باختصار الـ situation الحالي وليه محتاجين التغيير.

مثلًا:

Currently, our product endpoints are hitting the database directly, leading to high latency during peak hours.

الفكرة إنك تدي القارئ صورة كاملة عن المشكلة قبل ما يدخل في الحل.


📍 الـ Problem Statement
وضح المشكلة الأساسية اللي بتحاول تحلها بالأرقام لو أمكن.

مثلًا:

Average response time increased from 300ms to 900ms under load.

دي بتخلي الـ RFC منطقي ومبني على data.


📍 الـ Proposed Solution
اشرح الـ approach اللي ناوي تستخدمه، ليه اخترته، وإزاي هيشتغل.

مثلًا:

We'll use Redis to cache product data for 5 minutes. The cache will be invalidated on product update events.

ممكن كمان تضيف diagram بسيط أو pseudo code لو محتاج توضح flow معين.


📍 الـ Alternatives Considered
بيوضح إنك مش اخترت الحل عشوائي.

مثلًا:

Considered using in-memory cache, but it doesn’t scale horizontally. Redis fits better for distributed systems.

📍 الـ Trade-offs
قول بصراحة إيه العيوب اللي ممكن تحصل.

Cache invalidation adds complexity and increases operational overhead.

📍 الـ Impact / Risks
قول إيه اللي ممكن يتأثر في الـ system.

Adding caching could lead to stale data if invalidation fails.

📍 الـ Open Questions
ممكن تسيب في الآخر شوية أسئلة مفتوحة علشان التيم يناقشها:

Should we cache all products or only top 100 requested ones?

📍 الـ Next Steps
اختصر إيه اللي هيحصل بعد الموافقة.

If approved, implementation will start in sprint 25, and metrics will be collected after deployment.

———

💡 نصائح مهمة وأنت بتكتب RFC:

- خليك واضح وبسيط، بلاش مصطلحات تقيلة من غير داعي.
- استخدم bullet points علشان الناس تقرأ بسهولة.
- لو فيه diagrams أو code snippets، ضيفهم علشان تسهل الفهم.
- خليك مرن في النقاش... الهدف مش إن فكرتك تتنفذ، الهدف إن نختار أفضل حل.

———

مش مهم تكتب RFC مثالية من أول مرة، المهم إنك تبدأ، ومع الوقت هتتعلم إزاي توصل فكرتك بأوضح وأقوى طريقة ممكنة 🔥

———

وفقكم الله لكل خير 🌿

Harvard's "Advanced Algorithms"

📽 Videos: https://youtube.com/playlist?list=PL2SOU6wwxB0uP4rJgf5ayhHWgw7akUWSf

📷 Notes: https://people.seas.harvard.edu/~cs224/fall14/lec.html

🚀 C# Mastery Learning Path

A comprehensive guide to mastering C#, .NET, and related technologies from beginner to advanced level.

https://github.com/Metigator