دردشة سريعة عن الـ Vector Database 💡
.
.
لو ركزت شوية في معظم التطبيقات الذكية اللي موجودة في الوقت الحالي – من Google Search لحد ChatGPT و Netflix – هتلاقي إن فيه حاجة مشتركة بينهم: القدرة إنهم "يفهموا" اللي أنت بتدور عليه مش بس يطابقوا الكلمات.
الموضوع ده عمره ما كان هيبقى سهل بالـ Databases التقليدية اللي تعودنا عليها زي SQL أو NoSQL. وعلشان كده ظهر نوع جديد من قواعد البيانات اسمه: Vector Database.
الـ Vector Database اتعملت مخصوص عشان تحل مشكلة البحث بالـ "معنى" مش بالـ "كلمة"، ودي النقلة اللي خلت أي نظام ذكي يقدر يتعامل مع الـ Data بطريقة شبه تفكيرنا كبشر.
———
📌 يعني إيه Vector Database؟
الـ AI Models (زي NLP أو Computer Vision) لما تيجي تمثل أي معلومة – سواء نص، صورة، أو صوت – مش بتخزنها بشكلها الخام. هي بتحولها لحاجة اسمها Embedding Vector.
الـ Vector ببساطة عبارة عن Array أرقام (زي [0.23, -0.44, 0.91, …]) والأرقام دي بتعبر عن المعنى.
مثال:
- كلمة "cat" و "dog" هتلاقي الـ Vectors بتوعهم قريبين جدًا في الـ Space.
- لكن كلمة "car" هتكون بعيدة عنهم.
بالتالي البحث هنا بيبقى مش بالكلمة نفسها، بالـ Similarity في المعنى.
———
⚡️ إيه المشكلة مع الـ Databases العادية؟
- الـ MySQL أو MongoDB مصممين للـ Keyword Search. يعني تدور على كلمة "cat" يجيبلك Data فيها الكلمة دي بالحرف.
- لكن لو عايز تبحث عن حاجة شبه "cat" بالمعنى (زي "kitten" أو "cute animal")… هنا الـ Databases التقليدية مش هتساعدك.
———
💡 إيه وظيفة الـ Vector Database؟
1- تخزن الـ Vectors بشكل efficient.
2- تتيحلك تعمل Similarity Search أو Nearest Neighbor Search بسرعة كبيرة جدًا.
3- تخليك تقدر تسأل بالـ natural language وتاخد نتيجة دقيقة بالمعنى.
———
🛠 أمثلة عملية:
- الـ Recommendation Systems: زي Netflix أو Spotify لما يقترحوا حاجة شبه اللي بتحبها.
- الـ Semantic Search: تدور في Documents أو Emails عن "meeting" فيجيبلك حاجات ليها علاقة حتى لو الكلمة مش مكتوبة بالحرف.
- الـ Chatbots: زي ChatGPT لما يرد عليك من Knowledge Base باستخدام أقرب إجابة بالمعنى مش بالكلمة.
———
📂 أمثلة على Vector Databases:
- Pinecone
- Weaviate
- Milvus
- Qdrant
كمان فيه Extensions للـ Databases التقليدية زي PostgreSQL (pgvector).
———
الـ Vector Database مش بديل للـ SQL أو NoSQL، لكنها إضافة قوية جدًا للأنظمة اللي بتعتمد على الذكاء الاصطناعي.
هي السبب إن أي تطبيق ذكي النهارده يقدر يتعامل مع الـ Data بالمعنى مش بالكلمة.
———
وفقكم الله لكل خير 🌿
.
.
لو ركزت شوية في معظم التطبيقات الذكية اللي موجودة في الوقت الحالي – من Google Search لحد ChatGPT و Netflix – هتلاقي إن فيه حاجة مشتركة بينهم: القدرة إنهم "يفهموا" اللي أنت بتدور عليه مش بس يطابقوا الكلمات.
الموضوع ده عمره ما كان هيبقى سهل بالـ Databases التقليدية اللي تعودنا عليها زي SQL أو NoSQL. وعلشان كده ظهر نوع جديد من قواعد البيانات اسمه: Vector Database.
الـ Vector Database اتعملت مخصوص عشان تحل مشكلة البحث بالـ "معنى" مش بالـ "كلمة"، ودي النقلة اللي خلت أي نظام ذكي يقدر يتعامل مع الـ Data بطريقة شبه تفكيرنا كبشر.
———
📌 يعني إيه Vector Database؟
الـ AI Models (زي NLP أو Computer Vision) لما تيجي تمثل أي معلومة – سواء نص، صورة، أو صوت – مش بتخزنها بشكلها الخام. هي بتحولها لحاجة اسمها Embedding Vector.
الـ Vector ببساطة عبارة عن Array أرقام (زي [0.23, -0.44, 0.91, …]) والأرقام دي بتعبر عن المعنى.
مثال:
- كلمة "cat" و "dog" هتلاقي الـ Vectors بتوعهم قريبين جدًا في الـ Space.
- لكن كلمة "car" هتكون بعيدة عنهم.
بالتالي البحث هنا بيبقى مش بالكلمة نفسها، بالـ Similarity في المعنى.
———
⚡️ إيه المشكلة مع الـ Databases العادية؟
- الـ MySQL أو MongoDB مصممين للـ Keyword Search. يعني تدور على كلمة "cat" يجيبلك Data فيها الكلمة دي بالحرف.
- لكن لو عايز تبحث عن حاجة شبه "cat" بالمعنى (زي "kitten" أو "cute animal")… هنا الـ Databases التقليدية مش هتساعدك.
———
💡 إيه وظيفة الـ Vector Database؟
1- تخزن الـ Vectors بشكل efficient.
2- تتيحلك تعمل Similarity Search أو Nearest Neighbor Search بسرعة كبيرة جدًا.
3- تخليك تقدر تسأل بالـ natural language وتاخد نتيجة دقيقة بالمعنى.
———
🛠 أمثلة عملية:
- الـ Recommendation Systems: زي Netflix أو Spotify لما يقترحوا حاجة شبه اللي بتحبها.
- الـ Semantic Search: تدور في Documents أو Emails عن "meeting" فيجيبلك حاجات ليها علاقة حتى لو الكلمة مش مكتوبة بالحرف.
- الـ Chatbots: زي ChatGPT لما يرد عليك من Knowledge Base باستخدام أقرب إجابة بالمعنى مش بالكلمة.
———
📂 أمثلة على Vector Databases:
- Pinecone
- Weaviate
- Milvus
- Qdrant
كمان فيه Extensions للـ Databases التقليدية زي PostgreSQL (pgvector).
———
الـ Vector Database مش بديل للـ SQL أو NoSQL، لكنها إضافة قوية جدًا للأنظمة اللي بتعتمد على الذكاء الاصطناعي.
هي السبب إن أي تطبيق ذكي النهارده يقدر يتعامل مع الـ Data بالمعنى مش بالكلمة.
———
وفقكم الله لكل خير 🌿
❤9
🎯 فاهم يعني إيه Observer Pattern؟
.
.
"إزاي أخلي الأجزاء المختلفة في النظام (system) تتواصل مع بعض وتعرف إن فيه تغيير حصل… من غير ما أربط كل حاجة ببعضها وأخلي الكود معقد ومليان dependencies؟"
الموضوع يبان بسيط في الأول، بس أول ما تدخل في مشروع كبير، تلاقي الدنيا بقت spaghetti code… كل function مربوطة بالتانية، وأي تعديل صغير ممكن يبوظلك أجزاء تانية في الـ app.
في هندسة البرمجيات، فيه بعض الحلول والطرق متفق عليها بتخلّي السيستم modular، سهل الصيانة، وسهل التوسع. الحلول دي بنسميها Design Patterns.
واحد من أهم وأشهر الـ patterns اللي بيتكرر وجوده في مجالات مختلفة هو:
Observer Pattern
الـ pattern ده فكرته عامة جدًا، وممكن تلاقيه مستخدم في الـ events أو real-time updates أو distributed systems، أو حتى في أي application محتاج يتعامل مع تغييرات في state ويشاركها مع أجزاء تانية...
———
🟢 الفكرة ببساطة:
الـ Observer Pattern بيشتغل كده:
- عندك Subject: ده الـ object اللي بيمتلك الـ state.
- عندك Observers: مجموعة objects عايزين يتبلغوا بأي تغيير في الـ state.
أول ما الـ Subject يتغير، يبعت notification لكل Observers، وكل واحد فيهم يعمل update لنفسه بطريقته.
المهم إن الـ Subject مش محتاج يعرف التفاصيل عن كل Observer… مجرد يقول "أنا اتغيرت" وخلاص.
———
🟢 مثال من أرض الواقع:
تخيل إنك عامل subscribe لقناة على YouTube:
- القناة = Subject
- المشتركين = Observers
أول ما القناة تنزل فيديو جديد، يوتيوب بيبعت Notification للكل. القناة مش بتسأل "فلان عايز notification إزاي"… هي بس بتبعت والكل يتصرف.
———
🟢 ليه الـ Observer Pattern مهم؟
1- بيقلل الـ tight coupling: الـ Subject مش بيعرف التفاصيل عن Observers.
2- بيكون فيه flexibility: تقدر تضيف أو تشيل Observers بسهولة.
3- بيسهل maintenance: أي تعديل بيبقى localized، مش هيبوظ باقي الـ code.
———
في React: لما الـ state تتغير، الـ component تعمل re-render… ده نفس فكرة الـ Observer.
في Angular (RxJS): الـ Observables streams هي abstraction قوية لفكرة الـ Observer.
في JavaScript Events: كل ما تعمل element.addEventListener، أنت فعليًا بتسجل Observer.
———
وفقكم الله لكل خير 🌿
.
.
"إزاي أخلي الأجزاء المختلفة في النظام (system) تتواصل مع بعض وتعرف إن فيه تغيير حصل… من غير ما أربط كل حاجة ببعضها وأخلي الكود معقد ومليان dependencies؟"
الموضوع يبان بسيط في الأول، بس أول ما تدخل في مشروع كبير، تلاقي الدنيا بقت spaghetti code… كل function مربوطة بالتانية، وأي تعديل صغير ممكن يبوظلك أجزاء تانية في الـ app.
في هندسة البرمجيات، فيه بعض الحلول والطرق متفق عليها بتخلّي السيستم modular، سهل الصيانة، وسهل التوسع. الحلول دي بنسميها Design Patterns.
واحد من أهم وأشهر الـ patterns اللي بيتكرر وجوده في مجالات مختلفة هو:
Observer Pattern
الـ pattern ده فكرته عامة جدًا، وممكن تلاقيه مستخدم في الـ events أو real-time updates أو distributed systems، أو حتى في أي application محتاج يتعامل مع تغييرات في state ويشاركها مع أجزاء تانية...
———
🟢 الفكرة ببساطة:
الـ Observer Pattern بيشتغل كده:
- عندك Subject: ده الـ object اللي بيمتلك الـ state.
- عندك Observers: مجموعة objects عايزين يتبلغوا بأي تغيير في الـ state.
أول ما الـ Subject يتغير، يبعت notification لكل Observers، وكل واحد فيهم يعمل update لنفسه بطريقته.
المهم إن الـ Subject مش محتاج يعرف التفاصيل عن كل Observer… مجرد يقول "أنا اتغيرت" وخلاص.
———
🟢 مثال من أرض الواقع:
تخيل إنك عامل subscribe لقناة على YouTube:
- القناة = Subject
- المشتركين = Observers
أول ما القناة تنزل فيديو جديد، يوتيوب بيبعت Notification للكل. القناة مش بتسأل "فلان عايز notification إزاي"… هي بس بتبعت والكل يتصرف.
———
🟢 ليه الـ Observer Pattern مهم؟
1- بيقلل الـ tight coupling: الـ Subject مش بيعرف التفاصيل عن Observers.
2- بيكون فيه flexibility: تقدر تضيف أو تشيل Observers بسهولة.
3- بيسهل maintenance: أي تعديل بيبقى localized، مش هيبوظ باقي الـ code.
———
في React: لما الـ state تتغير، الـ component تعمل re-render… ده نفس فكرة الـ Observer.
في Angular (RxJS): الـ Observables streams هي abstraction قوية لفكرة الـ Observer.
في JavaScript Events: كل ما تعمل element.addEventListener، أنت فعليًا بتسجل Observer.
———
وفقكم الله لكل خير 🌿
❤10
دردشة سريعة عن الـ Monolithic Architecture 💯
.
.
لما بنسمع كلمة Monolithic Architecture ممكن ييجي في دماغنا إنها حاجة قديمة خلاص ومبقتش تستخدم. بس الحقيقة إن الشكل ده من الـ architecture لسه موجود في مشاريع كتير، وساعات كمان بيكون هو الحل الأمثل في بدايات أي مشروع.
———
🔗 LinkedIn:
https://www.linkedin.com/posts/mentoor-io_softwaredevelopment-softwareengineering-softwaredeveloper-activity-7376275845306343426-xLsS
🔗 Facebook:
https://www.facebook.com/share/p/17K79YsdgW
.
.
لما بنسمع كلمة Monolithic Architecture ممكن ييجي في دماغنا إنها حاجة قديمة خلاص ومبقتش تستخدم. بس الحقيقة إن الشكل ده من الـ architecture لسه موجود في مشاريع كتير، وساعات كمان بيكون هو الحل الأمثل في بدايات أي مشروع.
———
🔗 LinkedIn:
https://www.linkedin.com/posts/mentoor-io_softwaredevelopment-softwareengineering-softwaredeveloper-activity-7376275845306343426-xLsS
🔗 Facebook:
https://www.facebook.com/share/p/17K79YsdgW
❤5
Clone Wars - Open Source Clones of Popular Sites
100+ open-source clones and alternatives of popular sites like Airbnb, Amazon, Instagram, Netflix, TikTok, Spotify, WhatsApp, YouTube, etc.
List contains source code, tutorials, demo links, tech stack, and GitHub stars count. Great for learning purpose!
https://github.com/GorvGoyl/Clone-Wars
❤5
This media is not supported in your browser
VIEW IN TELEGRAM
Beautiful React Loaders Collection 💯
React Loadly is a modern, high-performance library of React loaders, spinners, and loading indicators.
It’s built with TypeScript, optimized for Next.js / SSR, and designed with accessibility and developer experience in mind.
———
🔗 npm: https://www.npmjs.com/package/react-loadly
🔗 GitHub: https://github.com/Mostafashadow1/react-loadly
🔗 Showcase: https://mostafashadow1.github.io/react-loadly-showCases
❤7
من أهم المفاهيم اللي لازم تتعلمها في React 💯
.
.
بفضل الله، تم نشر أول مقال على مدونة JavaScript in Plain English على منصة Medium 🚀
.
.
The React Context API is a powerful feature for managing global state across a component tree, eliminating the need for prop drilling. Introduced in React 16.3, it’s beneficial for sharing data such as themes, authentication status, or user preferences.
———
Read Full Article 👇
https://medium.com/javanoscript-in-plain-english/mastering-react-context-api-best-practices-patterns-and-pitfalls-655e3410cae5
.
.
بفضل الله، تم نشر أول مقال على مدونة JavaScript in Plain English على منصة Medium 🚀
.
.
Mastering React Context API: Best Practices, Patterns, and Pitfalls 💯
The React Context API is a powerful feature for managing global state across a component tree, eliminating the need for prop drilling. Introduced in React 16.3, it’s beneficial for sharing data such as themes, authentication status, or user preferences.
———
Read Full Article 👇
https://medium.com/javanoscript-in-plain-english/mastering-react-context-api-best-practices-patterns-and-pitfalls-655e3410cae5
❤6
دردشة سريعة عن الـ WebRTC ⚡️
.
.
لو رجعنا كده بالذاكرة شوية لأول مرة جربت تعمل مكالمة فيديو أونلاين، أكيد كنت منبهر إنك شايف الشخص قدامك بالصوت والصورة في نفس الوقت. يمكن ما سألتش نفسك وقتها: إيه اللي بيحصل خلف الكواليس عشان التجربة دي تبان سهلة بالشكل ده؟
تخيّل إنك بتكلّم حد في دولة تانية… إزاي الصوت يطلع من عندك، يعدي على شبكة الإنترنت بكل تعقيداتها، يوصل له في أقل من ثانية، ومن غير ما يبقى فيه delay واضح؟
وإزاي الفيديو بيتبعت frame وراء التاني كأنه بث مباشر، رغم إن في النص فيه firewalls و NATs وراوترات، وكابلات بحرية بطول آلاف الكيلومترات؟
وهنا يظهر دور الـ WebRTC...
———
🔗 LinkedIn:
https://www.linkedin.com/posts/mentoor-io_mentoor-softwaredevelopment-softwaredeveloper-activity-7377714952352112640-Cs_-
🔗 Facebook:
https://www.facebook.com/share/p/1DUxGMUET3
🔗 Qabilah:
https://qabilah.com/posts/استكشف-سر-الـ-webrtc-كيف-تتواصل-في-الوقت-الحقيقي-بدون-تأخير~m8y4l4HD_0I
———
وفقكم الله لكل خير 🌿
.
.
لو رجعنا كده بالذاكرة شوية لأول مرة جربت تعمل مكالمة فيديو أونلاين، أكيد كنت منبهر إنك شايف الشخص قدامك بالصوت والصورة في نفس الوقت. يمكن ما سألتش نفسك وقتها: إيه اللي بيحصل خلف الكواليس عشان التجربة دي تبان سهلة بالشكل ده؟
تخيّل إنك بتكلّم حد في دولة تانية… إزاي الصوت يطلع من عندك، يعدي على شبكة الإنترنت بكل تعقيداتها، يوصل له في أقل من ثانية، ومن غير ما يبقى فيه delay واضح؟
وإزاي الفيديو بيتبعت frame وراء التاني كأنه بث مباشر، رغم إن في النص فيه firewalls و NATs وراوترات، وكابلات بحرية بطول آلاف الكيلومترات؟
وهنا يظهر دور الـ WebRTC...
———
🔗 LinkedIn:
https://www.linkedin.com/posts/mentoor-io_mentoor-softwaredevelopment-softwaredeveloper-activity-7377714952352112640-Cs_-
🔗 Facebook:
https://www.facebook.com/share/p/1DUxGMUET3
🔗 Qabilah:
https://qabilah.com/posts/استكشف-سر-الـ-webrtc-كيف-تتواصل-في-الوقت-الحقيقي-بدون-تأخير~m8y4l4HD_0I
———
وفقكم الله لكل خير 🌿
❤5
فيديو مهم جدًا 💯
- يعني إيه Documentation وليه مهمة جدًا.
- أنواع الـ Documentation المختلفة: README, Code Comments, API Docs, Architecture Docs, RFCs, OPDOCs.
- إزاي تكتب Docs فعّالة وسهلة تتفهم.
- الأخطاء الشائعة اللي بتبوّظ أي Documentation.
———
https://youtu.be/D92MZJboOxs
Documentation Best Practices | شركات كتير بتهمله رغم أهميته
- يعني إيه Documentation وليه مهمة جدًا.
- أنواع الـ Documentation المختلفة: README, Code Comments, API Docs, Architecture Docs, RFCs, OPDOCs.
- إزاي تكتب Docs فعّالة وسهلة تتفهم.
- الأخطاء الشائعة اللي بتبوّظ أي Documentation.
———
https://youtu.be/D92MZJboOxs
YouTube
Documentation Best Practices | شركات كتير بتهمله رغم أهميته
عمرك دخلت مشروع برمجة ومافهمتش منه حاجة؟ الكود موجود، بس مفيش أي توثيق (Documentation)... النتيجة؟ ضياع وقت ومجهود، وأخطاء كتير كان ممكن تتجنب.
في الفيديو ده هشارك معاكم:
- يعني إيه Documentation وليه مهمة جدًا.
- أنواع الـ Documentation المختلفة: README…
في الفيديو ده هشارك معاكم:
- يعني إيه Documentation وليه مهمة جدًا.
- أنواع الـ Documentation المختلفة: README…
❤3
مجموعة مقالات ممتازة تخص Node.js 💯
.
.
https://www.builder.io/blog/visual-guide-to-nodejs-event-loop
https://www.builder.io/blog/NodeJS-visualizing-nextTick-and-promise-queues
https://www.builder.io/blog/visualizing-nodejs-timer-queue
https://www.builder.io/blog/visualizing-nodejs-io-queue
https://www.builder.io/blog/visualizing-nodejs-io-polling
https://www.builder.io/blog/visualizing-nodejs-check-queue
https://www.builder.io/blog/visualizing-nodejs-close-queue
.
.
Part 1: Visualizing the Node.js Event Loop
https://www.builder.io/blog/visual-guide-to-nodejs-event-loop
Part 2: Visualizing nextTick and Promise Queues in Node.js
https://www.builder.io/blog/NodeJS-visualizing-nextTick-and-promise-queues
Part 3: Visualizing Timer Queue in Node.js
https://www.builder.io/blog/visualizing-nodejs-timer-queue
Part 4: Visualizing the I/O Queue in the Node.js Event Loop
https://www.builder.io/blog/visualizing-nodejs-io-queue
Part 5: Visualizing I/O Polling in the Node.js Event Loop
https://www.builder.io/blog/visualizing-nodejs-io-polling
Part 6: Visualizing the Check Queue in the Node.js Event Loop
https://www.builder.io/blog/visualizing-nodejs-check-queue
Part 7: Visualizing the Close Queue in the Node.js Event Loop
https://www.builder.io/blog/visualizing-nodejs-close-queue
❤4
🔐 الفرق بين Hashing و Encryption و Salting و Pepper
.
.
الأربع مصطلحات قريبين من بعض في إن كلهم ليهم علاقة بتأمين الـ data. بس الحقيقة إن كل واحد فيهم ليه هدف مختلف تمامًا وطريقة استخدام مختلفة، ولو خلطت بينهم أو استعملت حاجة مكان التانية هتعمل مشكلة كبيرة في السيستم بتاعك.
تخيل معايا إنك بتعمل منصة فيها مستخدمين بيسجلوا بالإيميل والباسورد. طبيعي إنك لازم تخزن الباسورد بشكل آمن، صح؟ هنا بقى السؤال:
- هل أخزن الباسورد زي ما هو plain text؟
- طب هل أعمله Encryption؟
- ولا Hashing كفاية؟
- طب إيه لازمة الـ Salt؟ وإيه الفرق بينها وبين الـ Pepper؟
———
الـ Hashing هو إنك بتحول الـ data (زي الباسورد) لسلسلة من الأرقام والحروف ملهاش معنى.
الميزة الأساسية: ده one-way، يعني تقدر تحول الباسورد لـ hash، لكن مستحيل ترجع من الـ hash للباسورد.
📌 الهدف: تستخدمه عشان تتحقق من البيانات، مش عشان تسترجعها.
مثال: المستخدم يدخل الباسورد، وأنت تعمله hash بنفس الـ algorithm وتقارن مع اللي مخزنه.
❌ المشكلة: لو اتنين مستخدمين عندهم نفس الباسورد، الـ hash بتاعهم هيبقى نفس النتيجة. وده بيخلي الموضوع عرضة لهجمات زي الـ Rainbow Tables.
———
الـ Encryption مختلف تمامًا. هنا بتعمل عملية reversible (يعني ينفع ترجع للبيانات الأصلية).
تخزن الـ data مشفرة، وتقدر تفكها بالـ key.
📌 الهدف: حماية البيانات اللي لازم تسترجعها زي الرسائل، الملفات، بيانات الكريدت كارد… إلخ.
مثال: تشفير رسالة في واتساب، المستقبل يقدر يفكها بالـ key والرسالة الأصلية ترجع.
❌ المشكلة: لو الـ key اتسرب، كل حاجة مكشوفة.
———
الـ Salt هو string عشوائي بتضيفه للباسورد قبل ما تعمله hash.
ليه؟ عشان تمنع الهجمات اللي بتعتمد على إن نفس الباسورد عنده نفس الـ hash.
📌 الهدف: تعمل كل hash مختلف حتى لو كلمات السر متشابهة.
مثال:
- مستخدم1 = "123456" + SaltA → hash1
- مستخدم2 = "123456" + SaltB → hash2
رغم إن الباسورد هو نفسه، لكن الـ hash مختلف.
———
الـ Pepper شبه الـ Salt لكن في نقطة مختلفة: بيكون secret value بتضيفه للباسورد قبل الـ hashing.
بعكس الـ Salt اللي ممكن يتخزن مع الـ hash، الـ Pepper مش بيتخزن في الداتابيز، بيتخزن في config آمن أو environment variable.
📌 الهدف: تضيف طبقة حماية إضافية ضد أي حد يسرق الداتابيز. حتى لو معاه الـ hashes + salts، لسه ناقصه الـ pepper.
———
كلمات السر لازم تتحفظ بالـ Hashing + Salt + Pepper، مش بالـ Encryption.
الـ Encryption مكانه في البيانات اللي لازم تسترجعها زي الرسائل أو الملفات.
———
وفقكم الله لكل خير 🌿
.
.
الأربع مصطلحات قريبين من بعض في إن كلهم ليهم علاقة بتأمين الـ 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 مكانه في البيانات اللي لازم تسترجعها زي الرسائل أو الملفات.
———
وفقكم الله لكل خير 🌿
❤13🔥5
دردشة سريعة عن الـ OAuth 2.0 💡
.
.
تخيل إنك داخل تسجّل في تطبيق جديد علشان تتابع كورسات، ولما جيت تسجّل، التطبيق قالك:
"تقدر تسجّل بحساب Google أو GitHub بدل ما تعمل أكونت جديد"
ضغطت على زرار "Continue with Google"، وGoogle طلبت منك تختار الإيميل وتوافق على شوية صلاحيات.
بعدها التطبيق فتح واشتغل وكأنك عملت sign up فعلًا...
إيه اللي حصل هنا؟ 🤔
اللي حصل بالضبط هو إن Google استخدمت حاجة اسمها OAuth 2.0.
———
ببساطة، الـ OAuth 2.0 هو بروتوكول authorization (مش authentication)، بيخلّي التطبيقات تقدر تاخد إذن من المستخدم عشان تدخل على جزء من معلوماته في service تانية (زي Google, Facebook, GitHub) من غير ما يعرفوا الباسورد بتاعتك.
يعني التطبيق اللي بتستخدمه مش بيشوف الباسورد بتاعتك، بس بياخد توكن مؤقت يقدر يستخدمه يدخل على الـ APIs اللي أنت وافقت عليها.
وده بيخلي العملية آمنة، وبيحافظ على الخصوصية بتاعتك.
———
تعال نمشي خطوة بخطوة في الـ 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 اللي وافقت عليه.
———
لو عندك API وعايز تأمنها، ممكن تستخدم OAuth 2.0 بحيث:
- أي Client مش هيقدر يوصل لـ API غير لما يقدّم Access Token صالح.
- الـ Backend بتاعك يقدر يتحقّق من التوكن (مثلًا JWT أو عن طريق introspection endpoint).
- تقدر تتحكّم في الصلاحيات عن طريق الـ scope (يعني مثلًا توكن معين يقدر يقرأ بس، وتوكن تاني يقدر يكتب ويعدّل).
- تقدر تسحب صلاحيات التوكن في أي وقت (Revoke).
بالتالي، OAuth 2.0 بيأمّن الـ APIs عن طريق إنه:
✅ بيقلل الاعتماد على كلمات المرور
✅ بيسمح بالـ delegation (تطبيق ياخد إذن من مستخدم يوصل لحاجة مش بتاعته)
✅ بيخلي الـ tokens مؤقتة، وممكن تتحكم في صلاحياتها ومدّتها
———
- الـ 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 من إنه يتسرق.
———
وفقكم الله لكل خير 🌿
.
.
تخيل إنك داخل تسجّل في تطبيق جديد علشان تتابع كورسات، ولما جيت تسجّل، التطبيق قالك:
"تقدر تسجّل بحساب 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 من إنه يتسرق.
———
وفقكم الله لكل خير 🌿
❤12