لوحة المتصدرين

طُوّرت على مدار تاريخ الإنترنت العديد من الأدوات والطرق للتأكد من حماية المواقع من الاختراق، أو على الأقل جعله مستعدًا لمجابهة ذلك الخطر. أيًا كان مشروعك، متجرًا إلكتروني، أو مدونة عصرية أو حتى موقعًا لإحدى الشركات، تجب مراعاة تدابير الحماية في كل الأوقات. إذا كنت مطور/مصمم ويب، فمهمتك لم تعد تقتصر على بناء صفحات ويب جميلة، بل عليك المحافظة عليها محمية من جميع الجهات التي قد ترغب باختراقك واستغلال موقعك. ستحتاج لإجراء تدابير أمنية لمنع حصول شيء كذلك. هنالك العديد من الطرق لاختراق المواقع، لذلك يجب وضع تدابير حماية متعددة لقطع جميع تلك الطرق. لكن لا وجود لطريقة محددة قادرة على حمايتك بالكامل من المخترقين، أفضل ما يمكنك فعله هو تصعيب المهمة على المخترقين على نحو كافِ لدرجة تجعلهم ييأسون من المحاولة. طرق الاختراق الشائعة كما أسلفنا، هناك العديد من الطرق يستعملها المخترقون لتخطي حماية الموقع بهدف تدميره أو التلاعب به. سنذكر هذه الطرق حتى يمكنك إجراء تدابير وقائية للتصدي لهذه المحاولات. حقن استعلامات SQL لا يمكن إنكار أن حقن استعلامات SQL‏ (SQL Injection) هي إحدى أكثر طرق الاختراق خطرًا على كل من المواقع والأنظمة. على نحو عام، تتضمن هذه الطريقة إدخال استعلامات SQL في حقول الإدخال مثل حقول تسجيل الدخول أو حتى شريط العناوين الخاص بالمتصفح. بفعل ذلك يتمكن المخترق من الوصول لقواعد البيانات الخاصة بالموقع أو النظام. عندما تدخل اسم المستخدم وكلمة السر في حقل تسجيل الدخوليُدرَج النص الذي أدخلته إلى استعلام SQL. ذلك الاستعلام سيفحص البيانات التي أدخلتها ويوازنها بقاعدة بيانات الموقع أو النظام. بمجرد تطابق القيم المدخلة مع المسجلة ستحصل على تصريح دخولك، إذا لم تتطابق فلا يسعك الدخول. حقن قواعد البيانات يحدث عندما يحاول المخترق إدراج استعلامات SQL في حقول الإدخال الخاصة بموقعك. في العادة سيفحص الموقع البيانات المدرجة ويتأكد من صلاحيتها. إذا حدث واحتوت بياناتك مجرد علامة اقتباس (‘) بنهاية بيانات اسم المستخدم قد تفسرها قاعدة البيانات كاستعلام SQL بنَّاء، وهكذا سيُعدُّ استعلامًا صحيحا. قد لا يدخل المخترقون إلى موقعك عن طريق ذلك الاستعلام بالتحديد، لكن هذه الطريقة ستسمح لهم بالوصول إلى اسم قاعدة بياناتك، والجداول وحقول المفاتيح. وبامتلاك هذه البيانات سيحتاجون فقط إلى إدخال استعلام SQL في أحد حقول موقعك، عندها سيتمكنون من رؤية كامل محتويات قاعدة بياناتك. كيف يمكن التصدي لحقن SQL التأكد من إدخال نوع البيانات الصحيح الاستعلام باستخدام الوسائط (Parameters) تحديد الصلاحيات ترشيح IIS موحَّد تفعيل توثيق طلبات الاستعلام فكر باستخدام إطار لربط العلاقات بالكائنات (ORM) هجمات XSS الهجمات بالسكربتات العابرة للمواقع Cross Site Scripting، التي تُعرف اختصارًا بهجمات XSS، هي إحدى أكثر طرق الاختراق التى يصعب التصدي لها. في الأعوام السابقة، واجه كلٌّ من Microsoft، و MySpace، و Google صعوبات كبيرة في التعامل مع تلك الهجمات. تعتمد هجمات XSS على إرفاق سكربتات خبيثة مكتوبة بلغة جافا سكربت بالروابط الداخلية بهدف التحكم بسجلات الجلسات (Sessions) الخاصة بالموقع، أو اختطاف الإعلانات أو سرقة المعلومات الشخصية. لابد أنك تذكر حدوث هذا: قمت بالضغط خطأً على إعلان غريب الشكل، فأرسلك إلى صفحة شبيهة بتطبيقات الدردشة. ثم ترى رسالة من فتاة لطيفة تطلب منك الضغط على رابط ما للدردشة معها. وعند الضغط على الرابط يظهر لك عنوان URL غريب الشكل مثل العنوان التالي: [%63%61%74%69%6f%6e%3d%274%74%70%3a%2f%2f%77%7…] قد تعتقد أن لا شئ قد حدث ولكن لا، أنت مخطئ بالتأكيد. هذه الروابط تساعد على سرقة ملفات تعريف الارتباط (Cookies) والتي بدورها تعين المخترق على سرقة معلوماتك الشخصية. كيف يمكنك التعامل مع برمجيات تخطي المواقع لا تسمح بإدخال بيانات غير موثوقة إلا إذا تطلب الأمر ذلك خلّص (Escape) وسوم HTML عند معالجة البيانات المدخلة للحقول خلّص خصائص العناصر قبل إدراج البيانات على الموقع خلّص نصوص JavaScript من الحقول حتى تتفادى تسلل بيانات غير موثوقة إلى قيم جافاسكريبت. تخطي الاستيثاق كما يوحي الاسم، تخطي الاستيثاق مخيف. يستهدف عادةً التطبيقات أو أنظمة إدارة المحتوى سيّئة التصميم، ويمكن له إحداث فوضى عارمة بموقعك. يحدث الاختراق على نحو مشابه للتالي: البحث وإيجاد صفحة تسجيل دخول ضعيفة الحماية. فتح الشفرات المصدرية للصفحة. نسخ الشفرات إلى محرر نصِّي. حذف تعليمات JavaScript الخاصة بإدارة التصاريح وتعديل رابط أو اثنين. حفظ التغييرات على النص البرمجي. فتح الملف البرمجي الجديد على متصفحك، سجل الدخول كما لو أنك تمتلك الموقع. وهكذا نجح الاختراق! هل موقعك عُرضة لهذا الاختراق؟ هذا يعتمد على إجابة الأسئلة التالية: هل يقوم خادم موقعك بتشغيل العمليات مستعملًا صلاحيات الجذر، أو مدير النظام، أو النظام المحلي أو حسابات إدارية أخرى؟ هل يُمنح موقعك/تطبيقك صلاحيات الوصول لقاعدة البيانات عبر حساب SA (بالنسبة لأوراكل) أو حسابات أخرى مشابهة؟ هل يمتلك تطبيقك القدرة على الوصول لقاعدة البيانات عبر حسابات تمتلك صلاحيات أعلى من المطلوب؟ هل تعمل الحوسبة الافتراضية بخادم موقعك باستعمال كل الصلاحيات أو بثقة كاملة ببيئات عمل J2EE و NET.؟ هل بالإمكان تحديد إمكانية الوصول لموارد موقعك باستعمال قدرات المنصة المستعملة؟ إذا أجبت بنعم ولو على سؤال واحد فموقعك معرَّض للخطر. كيف يمكنك حماية موقعك تطوير الموقع، واختبارات الأداء ومنهجية التطوير يجدر القيام بها باستعمال أقل صلاحيات ممكنة. تأكد من أن الحسابات التى تدير بيئة العمل محدودة الإمكانات بأقصى قدر ممكن. لا يجوز أن يستخدم خادم موقعك صلاحيات مدير النظام، أو صلاحيات الجذر، أو غيرها من الحسابات الحسّاسة. حدّدد صلاحيات حسابات المستخدمين بموقعك على نحو يتناسب مع حاجتهم. لا يجوز أن تحظى حسابات الشركاء بصلاحيات إدارية والعكس صحيح. عليك استخدام حسابات مختلفة لمهام مختلفة. التدابير الشائعة لمنع الاختراق حافظ على الملحقات والبرامج محدَّثة باستمرار لا شيء يسعد المخترق أكثر من برمجية/ملحق منتهي الصلاحية. عادةً هذه هي أهدافهم المفضلة لاحتوائها على أعطال، أو خلل أو ثغرة أمنية. هذا هو السبب الرئيسي لتحديثها أساسا. لنقلها بهذه الطريقة، أنت تستخدم نوعًا ما من أقفال الأبواب تم التحايل عليه ألاف المرات. هل تتوقع أن يواجه اللص التالي مشكلة في التعامل معها؟ لذا استمع لهذه النصيحة، حدّث الآن! استخدم كلمات مرور قوية كم مرة تمت التوصية بهذا؟ من المهم للغاية استعمال كلمات مرور قوية. ربما لا تدرك أن المخترقين يحاولون سرقة كلمات مرورك باستمرار. إذن، كيف ننشىء كلمة مرورفعّالة؟ طريقة التبديل هذه طريقة جيدة للحفاظ على كلمات مرورك آمنة. حسب المبدأ، عليك استبدال الأحرف والأرقام بأحرف خاصة باستخدام طريقتك الشخصية. مثلاً: استعمل رمز '@' عوضًا عن حرف 'a' استعمل رمز '$' عوضًا عن حرف 's' استعمل رمز '%' عوضًا عن المسافات استعمل الرقم '0' عوضًا عن حرف 'o' استعمل رمز '!' عوضًا عن حرف 'i' بهذه الطريقة قمنا بتحويل كلمة سر بسيطة مثل ‘whoisjohngalt’ إلى كلمة أكثر تعقيدًا ‘wh0!$j0hng@lt’. طريقة Business Insider ابتكرت مجلة Business Insider مؤخرًا طريقة لتشكيل كلمة مرور قوية يسهل تذكرها. طبقًا للمجلة عليك إنشاء كلمة مرور طويلة لأنها تجعل الحواسيب تستغرق وقتًا طويلًا لتكتشفها. المبدأ الرئيسي لهذه الطريقة هو إنشاء كلمات مرور طويلة جدًا باستخدام كلمات غير ذات علاقة بك أو ببعضها. استخدم أداة Google Webmaster لدى Google طريقة لمساعدتك في تأمين موقعك. باستعمال أدوات Webmaster ستحظى بتنبيهات في حال العثور على برمجيات خبيثة. في حال اختراقك وعدم قدرتك على إزالة الاختراق، ستساعدك غوغل عن طريق إضافة موقعك للقائمة السوداء مما يمنحك متسعًا من الوقت للتعامل مع البرمجيات الخبيثة بموقعك، أيضًا هذه الخدمة تتيح لك رؤية تفاصيل المشكلة المرصودة. لا تعرض رقم إصدار WordPress بجانب تحديثك لمنصة التدوين، عليك دائمًا منع المخترقين من معرفة أي من إصدارات WordPress تستعمله. فعل ذلك سيمنعهم من استغلال ثغرات الحماية في موقعك. يمكنك فعل ذلك بتعديل ملف functions.php الخاص بموقعك وإضافة التعليمات التالية: function remove_version() { return ''; } add_filter('the_generator', 'remove_version'); تشديد الحماية على ملف htaccess. عادةً، حماية ملف htaccess متساهلة افتراضيًّا، لكن يمكنك تخصيصها لحمايتك من الاختراق عبر التلاعب بعناوين URL، أو حقن قواعد البيانات أوغيرها. هنالك الكثير من الطرق لتعديل ملف htaccess. لكننا سنشير إلى أكثرها جدوى. تذكّردائمًا أخذ نسخ حتياطية من الملف. order allow,deny deny from all أضف الاستعلامات التالية لمنحك مزيدًا من الأمان، علمًا أنه لن يُسمَح بالوصول غير المرغوب فيه، وستمنع زواحف محركات البحث من الوصول إلى ملف wp-admin.php. يمكن تطبيق تعليمات مماثلة على ملفات أخرى مثل install.php و eror_log. RewriteEngine On RewriteBase / RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]RewriteRule ^(.*)$ - [F,L]RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]RewriteCond %{QUERY_STRING} tag\= [NC,OR]RewriteCond %{QUERY_STRING} ftp\: [NC,OR]RewriteCond %{QUERY_STRING} http\: [NC,OR]RewriteCond %{QUERY_STRING} https\: [NC,OR]RewriteCond %{QUERY_STRING} (\|%3E) [NC,OR]RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)||ê|"|;|\?|\*|=$).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*("|'|<|>|\|{||).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare).* [NC]RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$ RewriteRule ^(.*)$ - [F,L] الخاتمة التعرض للاختراق بالتأكيد محبط. أنت ترى ثمرة جهودك تنهار مثل برج رملي. لكن درهم وقاية سيكون دائمًا أفضل من دينار علاج، لذا بينما كل شيء على ما يرام قم بتحسين وإصلاح كل ما يمكن إصلاحه تحسبًا لوقوع الكوارث. ترجمة -وبتصرف- للمقال Security Advice for Preventing Your Website from Being Hacked من إعداد فريق موقع 1stwebdesigner

لطالما وفّر إطار العمل Laravel آليات سهلة للاستيثاق Authentication بالطرق التقليدية مثل استمارات Forms تسجيل الدخول في واجهة الوِب؛ إلا أن الأمر لم يكن سهلا بما فيه الكفاية بالنسبة للاستيثاق من الطلبات القادمة عبر واجهة تطبيقات برمجية. يأتي الإصدار 5.3 بحزمة جديدة، تُسمّى Passport، تهتم بتيسير استخدام Laravel لضبط خادوم Oauth وإعداده. يتناول هذا الدرس كيفية إعداد Laravel ليوفّر وظيفة خادوم Oauth اعتمادا على حزمة Passport. خادوم Oauth من المحتمل جدّا أنه سبق لك التعامل مع خادوم Oauth؛ مثلا عند استخدام حسابات على الشبكات الاجتماعية (فيس بوك، تويتر، … إلخ) للتسجيل في موقع على الشبكة. الفكرة التي تنبني عليها آلية الاستيثاق هذه هي تفويض عمليّة الاستيثاق إلى خادوم Oauth. نفترض مثلا أن لديك موقعا يستخدم هذه الآلية؛ عند تسجيل دخول الموقع عن طريق الحساب على فيس بوك فإن ما يحدُث هو التالي: يلج المستخدم إلى الموقع ويختار طريقة تسجيل الدخول (فيس بوك). يُنقَل المستخدم إلى صفحة تسجيل الدخول في فيس بوك حيثُ يُطلَب منه تسجيل الدخول إن لم يكن سبق له ذلك ثم يؤكّد سماحه لموقعك باستخدام حسابه على فيس بوك. يُعاد توجيه المستخدم إلى الموقع مع تسجيل دخوله إليه. يفترض هذا الدرس أن لديك إلماما بكيفية عمل خواديم Oauth للتصريح بالدخول. يمكن الاطّلاع على مقال مدخل إلى OAuth 2 للمزيد عن هذا الموضوع. إن كنتَ تبحث عن كيفية تسجيل الدخول إلى تطبيقك باستخدام حساب على موقع يوفّر وظيفة Oauth فراجع درس تسجيل الدخول عبر الشبكات الاجتماعية في Laravel باستخدام Socialite. إعداد خادوم Oauth على Laravel 5.3 يحتاج إعداد Passport على Laravel لتنفيذ بضعة أوامر وتحرير ملفات إعداد؛ إلا أن العملية عموما سهلة. ابدأ بتثبيت الإصدار 5.3 من Laravel: composer create-project --prefer-dist laravel/laravel laravel53oauth "5.3.*" نستخدم composer لإضافة حزمة Passport إلى متطلبات المشروع: composer require laravel/passport نسجّل مزوّد الخدمة Passport في ملفّ الإعداد config/app.php. افتح الملف ثم أضف السطر التالي إلى مصفوفة providers: Laravel\Passport\PassportServiceProvider::class, تأكّد من إعدادات قاعدة البيانات ثمّ نفّذ أمر التهجير Migration التالي: php artisan migrate ستلاحظ تنفيذ تهجيرات إضافية علاوة على تلك التي تأتي مبدئيّا مع Laravel: Migration table created successfully. Migrated: 2014_10_12_000000_create_users_table Migrated: 2014_10_12_100000_create_password_resets_table Migrated: 2016_06_01_000001_create_oauth_auth_codes_table Migrated: 2016_06_01_000002_create_oauth_access_tokens_table Migrated: 2016_06_01_000003_create_oauth_refresh_tokens_table Migrated: 2016_06_01_000004_create_oauth_clients_table Migrated: 2016_06_01_000005_create_oauth_personal_access_clients_table يأتي مزوّد الخدمة Passport مع تهجيرات لإنشاء جداول تخزّن عملاء Client التطبيق ومعلومات رموز الوصول Access tokens. ثم ننفّذ الأمر التالي الذي سيولّد مفاتيح التعميّة Encryption keys الخاصّة بمشروع كما أنه ينشئ رموز الوصول ويخزّنها في جدول البيانات المناسب: php artisan passport:install ننتقل الآن إلى نموذج المستخدم User ونضيف إليه السّمة Trait المسمّاة HasApiTokens. يُصبح النموذج على النحو التالي (بعد نزع التعليقات للاختصار): <?php namespace App; use Illuminate\Notifications\Notifiable; use Illuminate\Foundation\Auth\User as Authenticatable; // استيراد السّمة use Laravel\Passport\HasApiTokens; class User extends Authenticatable { // استخدام السمة use HasApiTokens, Notifiable; protected $fillable = [ 'name', 'email', 'password', ]; protected $hidden = [ 'password', 'remember_token', ]; } توفّر هذه السّمة مجموعة من الدوال المساعدة التي تتيح الحصول على رموز الوصول الخاصّة بالمستخدمين ومدى الصلاحيّات Permissions scope المتاح للعميل. الخطوة المواليّة هي استدعاء الدالة Passport::routes ضمن الدالة boot الموجودة في مزوّد خدمة الاستيثاق app/Providers/AuthServiceProvider.php: public function boot() { $this->registerPolicies(); Passport::routes(); } لا تنس استدعاء الصنف Laravel\Passport\Passport في مزوّد خدمة الاستيثاق: use Laravel\Passport\Passport; يمكنك ملاحظة المسارات الجديدة التي أضافتها الدالة Passport::routes بتنفيذ أمر Artisan التالي الذي يسرُد لائحة بالمسارات الموجودة في المشروع: php artisan route:list الخطوة الأخيرة هي تعديل ملف الإعداد config/auth.php وتحديد قيمة driver في المصفوفة api لتصبح passport بدلا من token: 'api' => [ 'driver' => 'passport', 'provider' => 'users', ], يعتمد Laravel مبدئيا على رموز للاستيثاق من الطلبات القادمة عبر واجهة التطبيقات البرمجية؛ إلا أن هذه الرموز المبدئية لا تتيح إلا القليل من الخيارات، عكس ما يوفّره Passport. بهذا نكون أنهينا إعداد Laravel لأداء وظيفة خادوم Oauth. اختبار خادوم Oauth المرحلة المواليّة بعد إعداد Laravel ليعمل خادوم Oauth هي اختبار ما أعددناه. سنحتاج لعميل نجرّب عن طريقه الاستيثاق من الخادوم. نعيد النظر، قبل الانتقال للجانب التطبيقي من الاختبار، في كيفية الاستيثاق من مستخدم في خادوم Oauth. تضمّ العمليّة ثلاثة أطراف: المستخدِم، الخادوم والعميل. يريد المستخدِم تسجيل الدخول إلى العميل بالاعتماد على معلوماته الموجودة في الخادوم: ينقُل العميل المستخدِم إلى صفحة تسجيل الدخول على الخادوم. يُسجّل المستخدم الدخول إلى حسابه على الخادوم عن طريق بريده الإلكتروني وكلمة السّر. يتحقّق الخادوم من بيانات المستخدِم، ثم ينشئ - إذا كانت البيانات صحيحة - رمز وصول خاصًّا بالمستخدِم ويعيده إلى العميل. يستعمل العميل رمز الوصول الذي أرسله إليه الخادوم في طلباته المقبلة للتدليل على أن المستخدم فوّضه التعامل باسمه مع الخادوم. إنشاء مستخدمين للاختبار نبدأ بإنشاء مستخدمين لتجربة الاستيثاق. ننفذ أمر Artisan التالي لإنشاء صنف بذر Seed جديد: php artisan make:seeder UsersTableSeeder ثم نعدّل الدالة run لإنشاء مستخدمَيْن جديديْن: public function run() { $user1 = [ 'name' => 'Med Ahmed Eyil', 'email' => 'medeyil@laravel.com', 'password' => Hash::make('1234'), ]; $user2 = [ 'name' => 'Fatima Benziane', 'email' => 'fbenziane@laravel.com', 'password' => Hash::make('4567'), ]; User::create($user1); User::create($user2); } لا تنس استيراد النموذج User: use App\User; ثم نعتمد صنف البذر بتعديل الدالة run في الصنف DatabaseSeeder: public function run() { $this->call(UsersTableSeeder::class); } ثم ننفذ أمر البذر: php artisan db:seed جهّزنا الآن طرفيْن من الأطراف الثلاثة التي تحدثنا عنها، بقي العميل. إعداد العميل يوفّر Laravel بواسطة Passport مسارات من بينها المسار oauth/token/ الذي يمكّن من الحصول على رمز وصول. ينتظر المسار المعطيَات التاليّة: طريقة منح الصلاحيّة grant_type. معرّف المستخدم client_id. عبارة سر العميل client_secret. يحدّد المعطى grant_type طريقةَ توليد رموز الوصول. بما أننا نريد أن يطلُب الخادوم من المستخدم بريده الإلكتروني وكلمة السّر لكي يولّد رمز وصول للتطبيق العميل، فإن هذا المعطى سيأخذ القيمة password. يمكن لهذا المعطى أن يأخذ قيما أخرى حسب الطريقة التي تريد للتطبيقات العميلة أن تصل بها إلى موارد محميّة على خادومك. يعيّن المعطى الثاني معرّف العميل الذي نريد الاستيثاق منه؛ أما عبارة السّر فمهمتها إثبات أن العميل لديه ترخيص للاستيثاق بخادوم Oauth الذي أعددناه. سنحتاج أيضا لتمرير بريد المستخدم الإلكتروني وكلمة سره، بما أننا اخترنا طريقة password لتوليد الرموز. نعود لمشروع Laravel حيث يوجد الخادوم ثم ننفذ الأمر التالي: php artisan passport:client --password What should we name the password grant client? [Laravel Password Grant Client]: > Academy Password Client Password grant client created successfully. Client ID: 3 Client Secret: 17ZNjWn5A1I3mYOhGXZQFNACTdyt9Nwxup9jXG4M يطلُب الأمر أعلاه إنشاء تصريح لعميل للاستيثاق بخادوم Oauth ويحدّد طريقة توليد رموز الوصول بـpassword. يطلُب الأمر اسمًا للعميل ثم بعد كتابته وتأكيده يمنحنا معرّفا للعميل وعبارة سرّ. ملحوظة: رمز الوصول المولَّد فريد Unique، القيمة التي ستظهر لديك مختلفة حتما عن القيمة الظاهرة هنا. نعرّج قليلا، قبل الانتقال إلى العميل، على قاعدة البيانات وننظر في الجدول oauth_clients. لاحظ في الجدول وجود العميل الذي أنشأناه للتو، إضافة إلى عميليْن آخرين؛ أنشأهما الأمر passport:install عندما نفّذناه. تمكن ملاحظة أن قيمة العمود password_client بالنسبة للعميل الذي أنشأناه هي 1 للدلالة على أنه من نوع password. نأتي الآن للعميل، الذي يمكن أن يكون تطبيق وِب، تطبيقا للأجهزة المحمولة أو غيره. بالنسبة لي سأختار إضافة Postman على متصفح Chrome، وهي إضافة تمكّن من اختبار واجهات التطبيقات البرمجية. إرسال الطلبات نشغّل خادوم Passport بتنفيذ الأمر: php artisan serve ثم نفتح واجهة Postman ونعطيه المسار oauth/token/ ونمرّر له المعطيات التي تحدّثنا عنها سابقا. نحدّد نوع الإجراء بـ POST، ونختار تبويب Body لأننا في صدد ذكر بيانات جسم الطلب، ونختار x-www-form-urlencode للترميز. يؤدي استخدام الترميز x-www-form-urlencode إلى إرسال البيانات بنفس الطريقة التي تُرسَل بها بيانات استمارة Form على موقع وِب باستخدام الإجراء POST. إن كنتَ تُفضّل سطر الأوامر فبإمكانك تنفيذ أمر curl التالي والذي يؤدي نفس المهمّة (الخيار d- لاستخدام الترميز x-www-form-urlencode): curl -d "grant_type=password&client_id=3&client_secret=17ZNjWn5A1I3mYOhGXZQFNACTdyt9Nwxup9jXG4M&username=medeyil@laravel.com&password=1234" http://localhost:8000/oauth/token نحصُل بعد ذكر المعطيات الصحيحة وتنفيذ الطلب على الرد التالي: { "token_type": "Bearer", "expires_in": 31536000, "access_token":"رمز طويل هنا" , "refresh_token": "رمز طويل هنا" } تتضمن الإجابة أربعة حقول: نوعية الرمز token_type. يعني النوع bearer أن بإمكان الرمز منح الوصول إلى الخادوم دون الحاجة لذكر معلومات إضافية (مثل مفاتيح التعمية). مدة صلاحيّة الرمز expires_in. يحدّد مدّة صلاحيّة الرمز، بالثواني. يحدّد Laravel مبدئيا مدة طويلة (حوالي سنة)؛ إلا أنه يمكن تغيير هذه المدة. رمز الوصول access_token. رمز التحديث refresh_token. يُستخدَم لطلب رمز وصول جديد عند انتهاء مدة صلاحية رمز الوصول الحالي. حصلنا على رمز الوصول؛ سنرى الآن كيفية استخدامه للوصول إلى موارد على الخادوم. يُرسِل العميل من الآن فصاعدا رمزَ الوصول الذي حصل عليه مع كل طلب موجّه للخادوم يحتاج للاستيثاق. إن نظرت في ملفّ مسارات واجهة التطبيقات البرمجية routes/api.php فستجد أن المسار user/ محميّ بـ auth:api: Route::get('/user', function (Request $request) { return $request->user(); })->middleware('auth:api'); يعني هذا أنه يتوجّب على المستخدم تقديم بيانات الاستيثاق الخاصّة بواجهة التطبيقات، التي جعلناها تعتمد على التعريف passport، حتى يتمكن من الحصول على المورِد (الذي هو في المثال أعلاه بيانات المستخدم الذي أرسل الطلب). نعود لـPostman لطلب المسار api/user/ مع تقديم رمز الوصول الذي حصلنا عليه سابقا. ملحوظة: تنبغي إضافة api/ إلى جميع المسارات المعرّفة في الملف routes/api.php. نحدّد في خانة الترويسة Headers طبيعة المعلومات التي نريد تقديمها إلى المسار والإجراء GET المعرَّف في المسار user/ الخاص بواجهة التطبيقات. الترويسة التي نريد تحديد قيمتها هي Authorization (طلب استيثاق) وقيمتها هي: Bearer access_token حيث access_token رمز الوصول الذي حصلنا عليه في الخطوة السابقة، مسبوقا بنوع الرمز (Bearer). نحصُل على معلومات المستخدِم الذي قدّم الطلب. يمكن الحصول على نفس النتيجة بأمر curl التالي: curl -H "Authorization: Bearer access_token" http://localhost:8000/api/user يعني الخيار H- أننا نريد تضمين الترويسة التاليّة له في الطلب. نلاحظ أن الإجابات التي نحصُل عليها من خادوم Passport مهيّأة بصيغة JSON، وهو ما يجعل التعامل معها سهلا في التطبيقات العميلة على الأجهزة المحمولة والمتصفّحات. الخلاصة هي أننا استخدمنا بيانات المستخدم (البريد وكلمة السر) للحصول على رمز وصول من خادوم Passport ثم استخدمنا رمز الوصول هذا للاطلاع على موارد محميّة على الخادوم.