الـ Tokens و Sanctum
في المرحلة الأولى السيرفر كان شايل داتا كل مستخدم عنده، والمتصفح شايل رقم بس. هنا هنبدأ نقلب الفكرة: الـ client يشيل الإثبات بنفسه. وهنعرف ليه ده بقى ضروري لما المتجر كبر.
- تعرف المواقف اللي الـ Session بتقع فيها، وليه الـ Token جه
- تشرح يعني إيه Bearer Token، وليه مينفعش يتحط في الـ URL
- تفرّق بين Opaque و Self-contained وتعرف تمن كل واحد
- تفهم Sanctum من جوه، وليه SHA-256 ينفع للـ tokens رغم إنه مينفعش للباسوردات
1. ليه الـ Session مش كفاية؟
الـ Session حل ممتاز لموقع واحد بيفتحه متصفح. لكن shop-lab مش هيفضل كده. تخيّل إن المتجر كبر:
| الموقف | المشكلة مع الـ Session |
|---|---|
| عملت تطبيق موبايل للمتجر | التطبيق مش متصفح، ومفيش عنده cookies بنفس الطريقة، ولا CSRF ولا SameSite ليهم معنى عنده |
| السيرفرات بقت 10 | محتاج store مشترك، وكل request بيعمل lookup فيه |
| قسّمت النظام لـ services: أوردرات، دفع، شحن | كل service محتاجة تسأل الـ session store “مين ده؟” |
| شركة شحن عايزة تقرا أوردرات التجار | مش هتديها باسوردك، ومش هتفتحلها session |
الـ API على api.shop.com والموقع على shop.com |
الـ cookies بتتعقّد بين الـ domains |
الـ Session اتعملت لمتصفح واحد بيكلم موقع واحد، والـ Token اتعمل لأي client بيكلم أي service.
2. الـ Token (Bearer Token)
GET /api/orders HTTP/1.1
Host: api.shop-lab.test
Authorization: Bearer 7|kQ2xR9mZ4vT1pL8sN3wY6bH0cF5jDكلمة Bearer معناها “حامله”. يعني أي حد ماسك الـ token ده، السيرفر هيعتبره صاحبه، من غير ما يسأل أي سؤال تاني. زي الفلوس الكاش بالظبط: اللي في إيده الورقة هو اللي يصرفها.
والفرق الكبير عن الـ cookie إن المتصفح مش بيبعته لوحده. الكود بتاعك هو اللي بيحطه في الـ header. وعشان كده الـ CSRF مش مشكلة هنا، زي ما شفنا في المرحلة الأولى.
الـ Bearer Token بيدّي الصلاحية لأي حد ماسكه من غير أي إثبات تاني، فلازم يتحمى زي الباسورد: HTTPS بس، ومش في الـ URL، وبعمر محدود.
3. Opaque و Self-contained
الـ Opaque زي رقم دولاب الأمانات اللي في المرحلة الأولى. الرقم لوحده مبيقولش أي حاجة، ولازم الموظف يروح يدوّر في الدفتر.
الـ Self-contained زي كارنيه الجامعة. مكتوب عليه اسمك وكليتك وتاريخ انتهاؤه، وعليه ختم الجامعة. أي أمن في أي مبنى يبص على الختم ويعرف إنه سليم، من غير ما يتصل بشؤون الطلبة.
اتفرج على الاتنين جنب بعض: ابعت كام request وعدّ الـ queries، وبعدين اعمل logout وابعت تاني.
- queries للداتابيز
- 0
- آخر رد
- —
- queries للداتابيز
- 0
- آخر رد
- —
| Opaque | Self-contained (زي JWT) | |
|---|---|---|
| شكله | 7|kQ2xR9mZ… |
eyJhbGci….eyJzdWIi….SflKxw… |
| السيرفر بيتأكد منه إزاي | بيدوّر عليه في الداتابيز | بيتشيك على التوقيع حسابياً |
| كل request محتاج داتابيز؟ | أيوه | لأ |
| تقدر تلغيه فوراً؟ | أيوه، تمسح الصف | صعب، وده درس كامل بعد كده |
| حد يقدر يقرا اللي جواه؟ | مفيش حاجة جواه | أيوه، أي حد |
| مثال | Sanctum في لارافيل | JWT، وبيتستخدم في OpenID Connect |
الـ Opaque سهل تلغيه بس محتاج داتابيز في كل request، والـ Self-contained مش محتاج داتابيز بس صعب تلغيه.
4. Sanctum من جوه (Personal Access Tokens)
لما تعمل token لمستخدم، لارافيل بيرجّعلك نص شكله كده:
7|kQ2xR9mZ4vT1pL8sN3wY6bH0cF5jDaE2gU7iO1
│ └─ random 40 chars: the secret part
└─ id of the row in personal_access_tokensوفي جدول personal_access_tokens بيتخزن SHA-256 للجزء العشوائي، مش الـ token نفسه. لما request ييجي، لارافيل ياخد الـ id من أول النص، يجيب الصف، يعمل hash للجزء العشوائي ويقارنه. يعني الـ token بيظهر مرة واحدة بس لحظة ما تعمله. لو ضاع، بتعمل واحد جديد.
اعمل token، وابعت request بيه، وبعدين جرّب تبقى هاكر سرق الجدول:
| id | name | token (sha256) | abilities |
|---|---|---|---|
| فاضي | |||
- الـ request جه بـ
Bearer— - نفصل عند
|: الـ id = ? - نجيب الصف ده من الجدول
- نعمل SHA-256 للجزء العشوائي: …
- نقارن بالـ hash المتخزن (constant-time)
حاجات تانية في الجدول ده
abilities: صلاحيات الـ token. مثلاً token لتطبيق الشحن يقدرorders:readبس، ومايقدرش يعدّل.last_used_at: آخر مرة اتستخدم، عشان تعرض للمستخدم “الأجهزة المتصلة” وتعرف الـ tokens المهجورة.expires_at: تاريخ انتهاء، ولو مش محطوط الـ token بيفضل شغال لحد ما تمسحه.
Sanctum بيخزن hash للـ token، وده نفس مبدأ الباسورد: لو الداتابيز اتسرقت، الـ tokens متتسرقش معاها.
أسئلة الإنترفيو
فكّر في إجابتك الأول، وبعدين افتح السؤال.
01إيه الفرق بين Session و Token؟
في الـ Session الداتا على السيرفر والمتصفح شايل رقم في cookie بتتبعت أوتوماتيك. في الـ Token الـ client شايل الإثبات وبيبعته بنفسه في header. والـ Token ممكن يبقى opaque (بيتدوّر عليه) أو self-contained زي JWT (بيتأكد منه بالتوقيع).
02يعني إيه Bearer token، وليه مينفعش يتحط في الـ URL؟
Bearer يعني اللي ماسكه هو صاحبه من غير أي إثبات تاني، زي الكاش. ومينفعش في الـ URL لأن الـ URLs بتتسجل في logs السيرفرات والـ proxies وفي history المتصفح وممكن تتبعت في الـ Referer.
03Opaque ولا Self-contained؟
الـ Opaque رقم بيتدوّر عليه في الداتابيز في كل request، بس تقدر تلغيه فوراً. الـ Self-contained زي JWT بيتأكد منه بالتوقيع من غير داتابيز، بس صعب تلغيه قبل ما يخلص، وأي حد يقدر يقرا اللي جواه.
04ليه Sanctum بيستخدم SHA-256 للـ tokens رغم إنه سريع؟
لأن الـ slow hash بيحمي من التخمين، والتخمين بيبقى ممكن لما الباسورد يختاره بني آدم. لكن الـ token 40 حرف عشوائي، فمساحة الاحتمالات ضخمة لدرجة إن التخمين مستحيل، والبطء ملوش فايدة.
05ليه Sanctum بيخزن hash للـ token مش الـ token نفسه؟
عشان لو الداتابيز اتسربت، الهاكر ميقدرش يستخدم الـ tokens. اللي معاه hash، ولو بعته كأنه token السيرفر هيعمله hash تاني ويطلع حاجة مختلفة. نفس مبدأ تخزين الباسورد.