اذهب إلى المحتوى

البحث في الموقع

المحتوى عن 'كلمة السر'.

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المحتوى


التصنيفات

  • الإدارة والقيادة
  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • السلوك التنظيمي في المؤسسات
  • عالم الأعمال
  • التجارة والتجارة الإلكترونية
  • نصائح وإرشادات
  • مقالات ريادة أعمال عامة

التصنيفات

  • مقالات برمجة عامة
  • مقالات برمجة متقدمة
  • PHP
    • Laravel
    • ووردبريس
  • جافاسكربت
    • لغة TypeScript
    • Node.js
    • React
    • Vue.js
    • Angular
    • jQuery
    • Cordova
  • HTML
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • لغة C#‎
    • ‎.NET
    • منصة Xamarin
  • لغة C++‎
  • لغة C
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • لغة Rust
  • برمجة أندرويد
  • لغة R
  • الذكاء الاصطناعي
  • صناعة الألعاب
  • سير العمل
    • Git
  • الأنظمة والأنظمة المدمجة

التصنيفات

  • تصميم تجربة المستخدم UX
  • تصميم واجهة المستخدم UI
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب GIMP
    • كريتا Krita
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • نصائح وإرشادات
  • مقالات تصميم عامة

التصنيفات

  • مقالات DevOps عامة
  • خوادم
    • الويب HTTP
    • البريد الإلكتروني
    • قواعد البيانات
    • DNS
    • Samba
  • الحوسبة السحابية
    • Docker
  • إدارة الإعدادات والنشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
    • ريدهات (Red Hat)
  • خواديم ويندوز
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • شبكات
    • سيسكو (Cisco)

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح
  • مبادئ علم التسويق

التصنيفات

  • مقالات عمل حر عامة
  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • العمل الحر المهني
    • العمل بالترجمة
    • العمل كمساعد افتراضي
    • العمل بكتابة المحتوى

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
    • بريستاشوب
    • أوبن كارت
    • دروبال
  • الترجمة بمساعدة الحاسوب
    • omegaT
    • memoQ
    • Trados
    • Memsource
  • برامج تخطيط موارد المؤسسات ERP
    • تطبيقات أودو odoo
  • أنظمة تشغيل الحواسيب والهواتف
    • ويندوز
    • لينكس
  • مقالات عامة

التصنيفات

  • آخر التحديثات

أسئلة وأجوبة

  • الأقسام
    • أسئلة البرمجة
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات

التصنيفات

  • كتب ريادة الأعمال
  • كتب العمل الحر
  • كتب تسويق ومبيعات
  • كتب برمجة
  • كتب تصميم
  • كتب DevOps

ابحث في

ابحث عن


تاريخ الإنشاء

  • بداية

    نهاية


آخر تحديث

  • بداية

    نهاية


رشح النتائج حسب

تاريخ الانضمام

  • بداية

    نهاية


المجموعة


النبذة الشخصية

تم العثور على 3 نتائج

  1. أعرف أنني أتحدث كثيرًا عن أن مسؤولية أمن مواقع الوردبريس تقع على عاتق أصحابها. لكن من المعلوم أن هناك حالات حيث لا يملك أصحاب المواقع سيطرة كاملة على نقاط الضعف التي يتسبب بها المستخدمون خاصة الذين لا يلتزمون بوضع كلمات مرور ذكيةٍ وآمنة. لكي نكون منصفين، لنُفَكِر في حجم وعدد الاسماء، الأرقام، تواريخ أعياد الميلاد، العناوين، والمعلومات التي علينا تتبعها بصورة يومية. ثم لنعد التفكير في عدد التطبيقات التي نستعملها يوميًا. فآخر ما نتمناه هو حِفظُ كلمةِ مرورٍ فريدةٍ ومعقدةٍ لكل واحدة منها. ولكن حينما نصل إلى كلمات السر فلا يمكن التقصير في اختيارها ووضع أمن موقع الويب (أو المعلومات الخاصة بالمستخدم) على المحك لمجرد أننا لا نريد إنشاء كلمةَ مرورٍ أفضلَ من تلك التي أنشأناها على Gmail قبل سنواتٍ خلت. أيضًا، فكلمة السر الخاصة بموقع الوردبريس تلعب دورًا مهمًا في تعزيز أمن موقع ووردبريس الخاص بك. تاريخ كلمات المرور و وردبريس وضع الوردبريس منذ ظهوره مسؤولية ضمان قوة كلمات مرور مستخدمي مواقع الإنترنت على عاتق مطوري المواقع أنفسِهم. ومحاولةً للالتزام ببرتوكول OWASP 10، سَنَت ووردبريس عددا من التدابير الأمنية لحماية المستخدمين من الممارسات الخاطئة لكلمات المرور، نذكر منها: 1-نسخة 3.7 في تحديث 3.7، أضاف الورد بريس مؤشر قوة كلمة المرور أثناء إعداد الحساب وإعادة تعيين كلمة السر. وقد كان الغرض من ذلك هو إعطاء المستخدمين حافزًا لإنشاء كلمات مرورٍ أقوى. 2-نسخة 4.0 في عام 2014 مع الإصدار 4.0، بدأ وردبريس بإدخال خاصية غلق كل الحسابات المفتوحة لحظة تسجيل خروج المستخدم من نظام إدارة المحتوى. 3- نسخة 4.3 في عام 2015 أضاف وردبريس خاصية جديدة لكلمة المرور لمساعدة المستخدمين على إنشاء كلماتِ سِرٍ معقدة. وأضيفت ميزة أخرى (auto-populate) من شأنها أن تشجع المستخدمين على إنشاء كلماتِ مرورٍ قوية باقتراح من وردبريس. 4-الآن قامت ووردبريس بإضافة الميزات التالية لتحصين كلمة المرور: كل معلومات وملفات تسجيل دخول المستخدمين يتم تسييرها من جانب الخادم (server-side) تقديم حماية إضافية لكلمات السر من خلال تقنيات التمليح والتمدد (Salting and stretching techniques) نظام الإِذن من ووردبريس الذي يُقَيِد من لديه حق الوصول إلى معلومات المستخدم الخاصة مثل عنوان البريد الإلكتروني لمن قام بترك تعليقات أو إضافة للمحتوى لكن تم وَسمُهُ بعلامة “خاص”. السؤال الذي يتبادر إلى الاذهان هو لم يقوم الووردبريس بكل هذه المجهودات في سبيل تعزيز نظام كلمات المرور لديه. الاجابة بسيطة، فكلمةُ مرورٍ ضعيفة تفتح الباب على مصراعيه لكثيرٍ من المخاطر على مواقع الإنترنت، قد لا يتمكن فريق أمن وردبريس من جعل كل التحديثات تحدث بصورة آلية على نواة النظام أو يُفرَضُ على جميع المستخدمين استعمال مكونات الحماية والنسخ الاحتياطي الإضافية لكن باستطاعتهم أن يقوموا بكل ما في وِسعِهم لإجبارِ المستخدمين على اتخاذ قرارات أكثر ذكاءً أثناء الاشتراك و تسجيل الدخول. الطريقة الصحيحة لاستخدام كلمات المرور مع ووردبريس في عام 2016 قامت منظمة وردفنس (Wordfence) برصد لمواقع الانترنت لمدة 16 ساعة فكانت النتيجة كما يلي: "خلال هذه الفترة الزمنية رصدنا 6,611,909 هجمة، مستهدفةً 72,532 موقِعًا، رصدنا هجماتٍ كانت من قبل 8941 عنوان IP فريد، و كان متوسط عدد الهجمات 626 هجمة لكل موقعٍ ضحية" دون استعمال تدابير أمنية إضافية وِفق قواعد سليمة، فكل ما يحتاجه القراصنة هو كلمة مرور واحدة ضعيفة لِيَجعَلَ من موقعك عرضةً لمثل هذه الهجمات المتوحشة. هذا ما يؤدي الى تعريض موقعك، مستخدميك أو أي زائرِ لموقعك الالكتروني لهذا الخطر. لتجنب ذلك، فيما يلي 8 نقاط يُمكِن تطبيقُها لإنشاء كلماتِ مرورٍ أقوى على الوردبريس 1. الأخذ بنصائح الووردبريس تعودنا على هذا النوع من الاقتراحات البسيطة، لكن المهم هو الفكرة، يجب إنشاء كلمة مرورٍ مُعقدة. 2-إختيار كلمات مرورٍ طويلة يوصي الوردبريس باستعمال كلمات مرورٍ متكونة من أكثر من ستة أحرف. ومع ذلك، فكلمات المرور التي تحتوي من 10 إلى 50 حرفا يكون اختيارًا أمثل. 3- الجمع بين الأحرف والأرقام يُعتَبَرُ استعمال سلسلةٍ طويلةٍ من الأرقام غير كافٍ، بل يتوجب استعمال مزيجٍ من الأحرف الكبيرة والصغيرة، الأرقام والرموز عند إنشاء كلمات المرور. 4-تجنب استعمال كلمات المرور القديمة يجد بعض المستخدمين أنه من الممكن إعادة استعمال كلمات مرور قديمة سبق وأن تم إعادة تعيينها غير أنَه يتوجب تَجَنُب هذه السلوكيات. 5-التحديث إتباع كل القواعد المذكورة سابِقًا في إنشاء قواعد المرور يساعد على إنشاء كلماتِ مرورٍ قويةٍ يَصعُب كَسرُهَا مع ذلك فالسماح ببقاء نفس كلمة المرور لمدة طويلة يجعلها عُرضةً للتدهور، لذلك فمن الأفضل طلب من جميع المستخدمين تغيير كلمة المرورِ بشكل دوري(كل بضعة أشهر على سبيل المثال). 6-استعمال خاصية عاملين من التَعَرُف (Two-Factor Authentication) حتى باستعمال أقوى كلمات المرور وإتباع أفضل ممارسات الحفاظ على أمن كلمات مرور فهذا لا يجعل منها منيعةً تمامًا من الاختراق، و لتوفير حمايةً أكبر لمواقع الانترنت يُستَحسَن إضافة تقنية التَعَرُف بواسطة عاملين (Two-Factor Authentication)حيث يُتَطَلَب من المستخدمين تنشيطَ جهازٍ أو تطبيق ثانٍ (مثل Google Authenticator) إضافةً لإسم المستخدم و كلمة المرور الخاصة بهم لتأكيد هويتهم قبل السماح لهم بالولوج إلى النظام. 7-إستعمال إضافات الأمن المساعدة(Security Plugin) تسمح الإضافات الأمنية المساعدة بمراقبة الموقع والكشف عن الثغرات الأمنية به، يمكن أيضا استعمال هذه الإضافات للحدِ من محاولات تسجيل الدخول الفاشلة. بعض هذه الإضافات الأمنية تسمح بتدقيق كلمات مرور المستخدمين لتفرض عليهم استعمال كلمات مرورٍ أكثر قوةً. 8-إستعمال أدوات إدارة كلمات المرور يقترح دليل إنشاء كلمات المرور للوردبريس ما يلي "إن أفضل طريقة لإنشاء كلمة مرورٍ قوية هي باستعمال أداةُ إدارة كلمات المرور لتوليد مجموعةٍ عشوائيةٍ من الأحرفِ، الأرقامِ والرموز" قطع الووردبريس أشواطًا طويلة في سبيل تأمين تسجيل الدخول وتشجيع أفضل الممارسات لتوليد كلمات المرور، فاستعمال أدوات إدارة كلمات المرور ليس لعدم قدرة المستخدمين على إنشاء كلمات مرور طويلة ومعقدة بل يعود السبب إلى مشكلة صعوبة تذكر كلمات السر المعقدة هذه، لذلك فاستعمال أداة مساعدة يكون مفيدًا. يُمكِن تلخيص فوائد هذه الادوات في النقاط التالية: يمكن البحث عن كلمات المستخدم و كلمات المرور كلها في مكان واحد للولوج إلى المواقع و التطبيقات. يمكن تخزين و تأمين المعلومات الشخصية والحساسة الأخرى أيضًا، مثل معلومات بطاقة الائتمان. المساعدة في إنشاء كلمات مرور جديدة وقوية. عند تفعيل هذا النوع من الأدوات، تَشرَع في ملء تفاصيل تسجيل الدخول الخاصة بالمستخدم للمواقع المحفوظة. مما يتيح إدارة حسابات مستخدمين عِدَة لنفس الموقع. بينما لا يمكن فرض هذه الأدوات على كل المستخدمين، يتبقى لنا استعمالها بأنفسنا واقتراحها على معارفنا. خلاصة يُعتَبَر تأمين مواقع الوردبريس من كل الخروق الأمنية أمرًا صعبًا، فيوجد العديد من الطرق الملتوية التي يسلكها القراصنة ، لذلك لا يتوجب علينا ترك أمرًا بسيطًا وبديهيًا ككلمة المرور تَمُر دون تقويتها. الكل على دراية أن كلمة مرور قوية تؤدي إلى تجربة أكثر أمنًا على الإنترنت، لكنها ليست الخيار المُفَضَل للمستخدمين لما تَحمِلُه من إزعاج أثناء إنشاء كلمة مرور قوية ومعقدة وفريدة لكل موقع على يزورونه على الإنترنت. بتقديم الأدوات اللازمة للمستخدمين لتأمين كلمات السر الخاصة بهم سنعمل على تأمين نظام الدخول لمواقعنا على الوردبريس. ترجمة –وبتصرّف- للمقال A Complete Guide to WordPress Password Security لصاحبه Brenda Barron حقوق الصورة البارزة محفوظة لـ Freepik و Flaticon
  2. عند إعداد خادوم ويب توجد غالبًا أقسام من الموقع نرغب بتقييد الوصول إليها، تُوفِّر تطبيقات الويب عادةً طرق التصريح authorization والاستيثاق authentication الخاصّة بها، ولكن يُمكِن استخدام خادوم الويب بذاته لتقييد الوصول إن كانت هذه الطّرق غير كافية أو غير متوفّرة. سنشرح في هذا الدّرس كيف نحمي الممتلكات assets باستخدام كلمة سر على خادوم ويب Apache يعمل على Ubuntu. المتطلبات الأساسيةنحتاج للوصول إلى بيئة خادوم Ubuntu لكي نبدأ، نحتاج أيضًا لمستخدم غير جذري non-root مع صلاحيّات sudo من أجل تنفيذ مهام إداريّة administrative، لكي تتعلّم كيفيّة إعداد مستخدم بامتيازات sudo اتبع دليلنا للإعداد الأولي لخادوم Ubuntu 14.04. تثبيت حزمة أدوات Apache المساعدةسنستخدم أداة مُساعِدة utility تُدعى htpasswd من أجل إنشاء الملف الذي يقوم بتخزين كلمات السّر التي نحتاجها للوصول إلى المحتوى المُقيَّد لدينا، تُوجَد هذه الأداة في الحِزمة apache2-utils داخل المستودعات repositories في Ubuntu. نُحدِّث الذاكرة المؤقتة cache للحِزَم المحليّة ونُثبِّت الحِزمَة بكتابة هذا الأمر، سننتهز الفرصة أيضًا لتثبيت خادوم Apache2 في حال لم يكن مُثبّتًا لديك: sudo apt-get update sudo apt-get install apache2 apache2-utilsإنشاء ملف كلمات السرنستطيع الآن الوصول للأمر htpasswd واستخدامه لإنشاء ملف كلمات السّر والذي يستعمله خادوم Apache لاستيثاق authenticate المستخدمين، سنقوم بإنشاء ملف مخفي لهذا الغرض يُدعى htpasswd. بداخل دليل الإعدادات etc/apache2/. عند استخدام هذه الأداة لأوّل مرّة نحتاج لإضافة الخيار c- لإنشاء الملف المُحدَّد، نقوم بتحديد اسم مستخدم (في هذا المثال sammy) في نهاية الأمر لإنشاء مُدخَل جديد بداخل الملف: sudo htpasswd -c /etc/apache2/.htpasswd sammyسيتم سؤالنا عن تزويد كلمة سر وتأكيدها للمستخدم. نترك الوسيط c- لأي مستخدمين آخرين نرغب في إضافتهم: sudo htpasswd /etc/apache2/.htpasswd another_userإن قمنا بمشاهدة محتويات الملف نستطيع رؤية اسم المستخدم وكلمة السّر المُشفّرة لكل تسجيل record: cat /etc/apache2/.htpasswdsammy:$apr1$lzxsIfXG$tmCvCfb49vpPFwKGVsuYz. another_user:$apr1$p1E9MeAf$kiAhneUwr.MhAE2kKGYHK.إعداد استيثاق كلمة السر لخادوم Apacheالآن وبعد أن أصبحنا نمتلك ملف لأسماء المستخدمين وكلمات السّر في صيغة يستطيع خادوم Apache قراءتها، نحتاج لإعداد Apache لكي يتفحّص هذا الملف قبل تخديم محتوانا المحمي، بإمكاننا فعل هذا بطريقتين مختلفتين. الخيار الأول هو تحرير edit إعدادات Apache وإضافة حماية كلمة السّر إلى ملف المضيف الافتراضي virtual host file. يُعطينا هذا الخيار أداء أفضل بشكل عام لأنّه يتجنّب تكلفة قراءة ملفات إعدادات مُوزَّعة، إن كنت تملك هذا الخيار فإنّنا ننصح بهذا الأسلوب. إن لم تكن لدينا القدرة على تعديل ملف المضيف الافتراضي (أو كنّنا نستخدم مُسبقًا ملفات htaccess. لأغراض أخرى) نستطيع تقييد النفاذ باستخدام ملف htaccess.، يستخدم Apache ملفّات htaccess. من أجل السّماح لتعيين بعض عناصر الإعدادات داخل ملف في دليل المحتوى. العيب في هذا هو أنّه يجب على Apache إعادة قراءة هذه الملفّات عند كل طلب يتضمّن هذا الدّليل ممّا قد يؤثر على الأداء. اختر الخيار الذي يُناسِب احتياجاتك أدناه. إعداد التحكم بالنفاذ Access Control داخل تعريف المضيف الافتراضينبدأ بفتح ملف المضيف الافتراضي الذي نرغب بإضافة تقييد له، سنستخدم في مثالنا الملف 000-default.conf الذي يحمل المضيف الظاهري الافتراضي والمُثبَّت عبر حزمة apache في Ubuntu: sudo nano /etc/apache2/sites-enabled/000-default.confينبغي أن يبدو المحتوى داخل الملف مُشابِهًا لما يلي بعد إزالة التّعليقات: etc/apache2/sites-enabled/000-default.conf/ <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>يتم الاستيثاق على أساس كل دليل، سنحتاج لإعداد الاستيثاق إلى استهداف الدّليل الذي نرغب بتقييد الوصول إليه بواسطة كتلة <Directory ___>، في مثالنا سنقيّد الوصول إلى كامل جذر المستند document root ولكن نستطيع تعديل القائمة لاستهداف دليل مُحدَّد داخل مساحة الويب: etc/apache2/sites-enabled/000-default.conf/ <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined <Directory "/var/www/html"> </Directory> </VirtualHost>نُحدِّد داخل كتلة الدّليل أنّنا نرغب بإعداد استيثاق أساسي Basic، نختار من أجل AuthName اسم حقل يتم عرضه عند السؤال عن الاعتمادات credentials، نستخدم الأمر التوجيهي AuthUserFile ليشير إلى Apache عن ملف كلمات السّر الذي أنشأناه، سنحتاج أخيرًا إلى valid-user للوصول إلى هذا المورد، وهذا يعني أنّه سيتم السماح بالدخول لكل من يثبت صحّة هويته بكلمة سر: etc/apache2/sites-enabled/000-default.conf/ <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined <Directory "/var/www/html"> AuthType Basic AuthName "Restricted Content" AuthUserFile /etc/apache2/.htpasswd Require valid-user </Directory> </VirtualHost>عند الانتهاء نحفظ ونغلق الملف، نعيد تشغيل Apache لتنفيذ سياسة policy كلمات السّر: sudo service apache2 restartيجب الآن أن يكون الملف الذي حدّدناه محميًّا بكلمة سر. إعداد التحكم بالنفاذ Access Control باستخدام ملفات htaccess.إن كُنّا نرغب بإعداد حماية كلمة السّر باستخدام ملفّات htaccess. بدلًا من الطريقة السّابقة فينبغي أن نبدأ بتحرير ملف إعدادات Apache الرئيسي للسماح بملفّات htaccess.: sudo nano /etc/apache2/apache2.confنبحث عن الكتلة <Directory> من أجل الدّليل var/www/ الذي يحتوي جذر المستند، نقوم بتشغيل معالجة htaccess. بتغيير الأمر التّوجيهي AllowOverride داخل تلك الكتلة من “None” إلى “All”: etc/apache2/apache2.conf/ . . . <Directory /var/www/> Options Indexes FollowSymLinks AllowOverride All Require all granted </Directory> . . .عند الانتهاء نحفظ ونغلق الملف. نحتاج بعد ذلك لإضافة ملف htaccess. إلى الدّليل الذي نرغب بتقييد الوصول إليه، في هذا المثال سنقيّد الوصول إلى كامل جذر المستند (كامل الموقع) والذي يتواجد في المسار var/www/html/، ولكن يُمكننا وضع هذا الملف في أي دليل نرغب بتقييد الوصول إليه: sudo nano /var/www/html/.htaccessنُحدِّد بداخل هذا الملف أنّنا نرغب بإعداد استيثاق أساسي Basic، نختار من أجل AuthName اسم حقل يتم عرضه عند السؤال عن الاعتمادات credentials، نستخدم الأمر التوجيهي AuthUserFile ليشير إلى Apache عن ملف كلمات السّر الذي أنشأناه، سنحتاج أخيرًا إلى valid-user للوصول إلى هذا المورد، وهذا يعني أنّه سيتم السماح بالدخول لكل من يثبت صحّة هويته بكلمة سر: var/www/html/.htaccess/ AuthType Basic AuthName "Restricted Content" AuthUserFile /etc/apache2/.htpasswd Require valid-userنحفظ ونغلق الملف، نعيد تشغيل خادوم الويب لنحمي بكلمة سر كل المحتوى الموجود في الدّليل بواسطة الملف htaccess.: sudo service apache2 restartتأكيد استيثاق كلمة السرللتأكّد من أنّ المحتوى محمي لدينا نُجرِّب النفاذ إلى المحتوى المُقيَّد من متصفّح إنترنت، يجب أن يتم عرض مُحث prompt لاسم المستخدم وكلمة السّر يُشبه ما يلي: إن أدخلنا الاعتمادات الصحيحة سيتم السماح لنا بالنفاذ إلى المحتوى، وإن أدخلنا الاعتمادات الخاطئة أو ضغطنا على إلغاء Cancel سنشاهد صفحة الخطأ "Authorization Required": الخاتمة يجب أن يكون لدينا الآن كل ما نحتاجه لإعداد استيثاق أساسي لموقعنا، فلنضع في اعتبارنا أنّ حماية كلمة السّر يجب أن تكون جنبًا إلى جنب مع تشفير SSL كي لا يتم إرسال اعتماداتنا إلى الخادوم في شكل نص مُجرَّد plain text، يمكنك الإطلاع أيضا على كيفيّة إنشاء شهادة SSL موقّعة ذاتيًّا لاستخدامها مع Apache. ترجمة -وبتصرّف- لـ How To Set Up Password Authentication with Apache on Ubuntu 14.04 لصاحبه Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.
  3. عند إعداد خادوم ويب توجد غالبًا أقسام من الموقع نرغب بتقييد الوصول إليها، تُوفِّر تطبيقات الويب عادةً طرق التصريح authorization والاستيثاق authentication الخاصّة بها، ولكن يُمكِن استخدام خادوم الويب بذاته لتقييد الوصول إن كانت هذه الطّرق غير كافية أو غير متوفّرة. سنشرح في هذا الدّرس كيف نحمي الممتلكات assets باستخدام كلمة سر على خادوم ويب Nginx يعمل على Ubuntu. المتطلبات الأساسيةنحتاج للوصول إلى بيئة خادوم Ubuntu لكي نبدأ، نحتاج أيضًا لمستخدم غير جذري non-root مع صلاحيّات sudo من أجل تنفيذ مهام إداريّة administrative، لكي تتعلّم كيفيّة إعداد مستخدم بامتيازات sudo اتبع دليلنا للإعداد الأولي لخادوم Ubuntu 14.04. إن لم نقم مُسبقًا بتثبيت Nginx نستطيع تثبيته على جهازنا بكتابة ما يلي: sudo apt-get update sudo apt-get install nginxإنشاء ملف كلمات السرللبدء نحتاج لإنشاء الملف الذي سيحمل تركيبات أسماء المستخدمين وكلمات السّر، نستطيع فعل ذلك باستخدام أدوات OpenSSL المساعدة التي ربّما تكون متوفّرة مُسبقًا على خادومنا، وبشكلٍ بديل نستطيع استخدام الأداة المساعدة htpasswd المُصمّمة لهذا الغرض والمُضمّنة في الحِزمة apache2-utils (تستخدم ملفّات كلمات سر Nginx نفس الصّيغة التي تستخدمها Apache)، بإمكانك اختيار الطّريقة التي تفضّلها. إنشاء ملف كلمات السر باستخدام أدوات OpenSSL المساعدةإن كُنّا نملك OpenSSL مُثبتًا على خادومنا فبإمكاننا إنشاء ملف كلمات سر بدون أي حِزَم إضافيّة. سنقوم بإنشاء ملف مخفي يُدعى htpasswd. في دليل الإعدادات etc/nginx/ لتخزين تركيبات أسماء المستخدمين وكلمات السّر. نستطيع إضافة اسم مستخدم إلى هذا الملف باستخدام هذا الأمر، سنختار الاسم sammy ليكون اسم مستخدم لدينا، ولكن تستطيع استخدام أي اسم ترغب به: sudo sh -c "echo -n 'sammy:' >> /etc/nginx/.htpasswd"سنقوم بعد ذلك بإضافة كلمة سر مُشفّرة encrypted لاسم المستخدم بكتابة ما يلي: sudo sh -c "openssl passwd -apr1 >> /etc/nginx/.htpasswd"نستطيع إعادة هذه العمليّة من أجل أسماء مستخدمين آخرين، وبإمكاننا أن نرى كيف يتم تخزين أسماء المستخدمين وكلمات السّر المُشفّرة داخل الملف بكتابة ما يلي: cat /etc/nginx/.htpasswd sammy:$apr1$wI1/T0nB$jEKuTJHkTOOWkopnXqC1d1إنشاء ملف كلمات السر باستخدام الأدوات المساعدة لـ Apacheفي حين أنّ OpenSSL تستطيع تشفير كلمات السّر من أجل استيثاق Nginx، يجد معظم المستخدمين أنّه من الأسهل استخدام أداة مُساعِدة مبنيّة لهذا الغرض، تقوم الأداة المُساعِدة htpasswd الموجودة في الحزمة apache2-utils بتخديم هذا الأمر بشكل جيّد. نُثبِّت الحِزمة apache2-utils على خادومنا بكتابة ما يلي: sudo apt-get update sudo apt-get install apache2-utilsوالآن بعد أن أصبح بإمكاننا الوصول للأمر htpasswd نستطيع استخدامه لإنشاء ملف كلمات السّر الذي يستخدمه خادوم Nginx من أجل استيثاق المستخدمين، سنقوم بإنشاء ملف مخفي لهذا الغرض يُدعى htpasswd. بداخل دليل الإعدادات etc/nginx/. عند استخدام هذه الأداة لأوّل مرّة نحتاج لإضافة الخيار c- لإنشاء الملف المُحدَّد، نقوم بتحديد اسم مستخدم (في هذا المثال sammy) في نهاية الأمر لإنشاء مُدخَل جديد بداخل الملف: sudo htpasswd -c /etc/nginx/.htpasswd sammyسيتم سؤالنا عن تزويد كلمة سر وتأكيدها للمستخدم. نترك الوسيط c- لأي مستخدمين آخرين نرغب في إضافتهم: sudo htpasswd /etc/nginx/.htpasswd another_userإن قمنا بمشاهدة محتويات الملف نستطيع رؤية اسم المستخدم وكلمة السّر المُشفّرة لكل تسجيل record: cat /etc/nginx/.htpasswdsammy:$apr1$lzxsIfXG$tmCvCfb49vpPFwKGVsuYz. another_user:$apr1$p1E9MeAf$kiAhneUwr.MhAE2kKGYHK.إعداد استيثاق كلمة السر لخادوم Nginxالآن وبعد أن أصبحنا نمتلك ملف لأسماء المستخدمين وكلمات السّر في صيغة يستطيع خادوم Nginx قراءتها، نحتاج لإعداد Nginx لكي يتفحّص هذا الملف قبل تخديم محتوانا المحمي. نبدأ بفتح ملف إعدادات الحجب للخادوم والذي نرغب في إضافة تقييد restriction له، سنستخدم في مثالنا هذا ملف الخادوم الافتراضي default للحجب والمُثبَّت عبر حزمة Nginx في Ubuntu: sudo nano /etc/nginx/sites-enabled/defaultينبغي أن يبدو المحتوى داخل الملف مُشابِهًا لما يلي بعد إزالة التّعليقات: /etc/nginx/sites-enabled/default server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name localhost; location / { try_files $uri $uri/ =404; } }نحتاج لإعداد الاستيثاق أن نقرّر السياق context الذي نريد تقييده، يسمح لنا Nginx من بين الخيارات الأخرى بتعيين التقييد على مستوى الخادوم أو بداخل موقع مُحدَّد، سنقوم في مثالنا بتقييد كامل المستند root بحجب على المكان، ولكن بإمكانك تعديل هذه القائمة لكي تستهدف فقط دليل مُحدَّد ضمن مجال الويب. نستخدم ضمن هذا الحجب على المكان الأمر التوجيهي auth_basic لتشغيل الاستيثاق واختيار اسم نطاق ليتم عرضه للمستخدم عند المطالبة بالاعتمادات credentials، سنستخدم الأمر التوجيهي auth_basic_user_file لكي يشير لخادوم Nginx إلى ملف كلمات السّر الذي أنشأناه: /etc/nginx/sites-enabled/default server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name localhost; location / { try_files $uri $uri/ =404; auth_basic "Restricted Content"; auth_basic_user_file /etc/nginx/.htpasswd; } }بعد أن ننتهي نحفظ ونغلق الملف، نعيد تشغيل خادوم Nginx لتنفيذ سياسة policy كلمات السّر لدينا: sudo service nginx restartيجب أن يكون الدليل الذي حددناه محميًّا الآن بكلمة سر. تأكيد استيثاق كلمة السرللتأكّد من أنّ المحتوى محمي لدينا نُجرِّب النفاذ إلى المحتوى المُقيَّد من متصفّح إنترنت، يجب أن يتم عرض مُحث prompt لاسم المستخدم وكلمة السّر يُشبه ما يلي: إن أدخلنا الاعتمادات الصحيحة سيتم السماح لنا بالنفاذ إلى المحتوى، وإن أدخلنا الاعتمادات الخاطئة أو ضغطنا على إلغاء Cancel سنشاهد صفحة الخطأ "Authorization Required": الخاتمةيجب أن يكون لدينا الآن كل ما نحتاجه لإعداد استيثاق أساسي لموقعنا، فلنضع في اعتبارنا أنّ حماية كلمة السّر يجب أن تكون جنبًا إلى جنب مع تشفير SSL كي لا يتم إرسال اعتماداتنا إلى الخادوم في شكل نص مُجرَّد plain text، يمكنك الإطلاع أيضا على كيفيّة إنشاء شهادة SSL موقّعة ذاتيًّا لاستخدامها مع Nginx. ترجمة -وبتصرّف- للمقال: How To Set Up Password Authentication with Nginx on Ubuntu 14.04 لصاحبه Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.
×
×
  • أضف...