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

برنامج Git هو أحد التطبيقات النادرة التي تمكنت من جمع العديد من تقنيات الحوسبة في برنامج واحد انتهى به المطاف ليصبح بنية تحتية تخدم عدَّة تطبيقات أخرى. على الرغم من أنّ التطبيق اشتهر بتتبع التعديلات على الشفرة المصدرية خلال مراحل التطوير، إلّا أنّ لديه استخدامات أخرى لجعل طريقة عملك كمطور أسهل وأكثر تنظيما. سنستعرض في ما يلي استخدامًا إضافيًّا لتطبيق Git. كان إنشاء مواقع الويب، إلى عهد قريب، بسيطًا للغاية وسحريًا في آن واحد. في الأزمان الغابرة للإصدار الأول من الويب Web 1.0 (هذا المصطلح لم يكن مستخدمًا حينها) كان بإمكانك زيارة أي موقع ويب، واستعراض شفرته المصدرية ثم برمجة ملفات HTML عكسيًّا (Reverse engineering)، بتنسيقاته السطرية وتصميمه المعتمد على الجداول، وتعدُّ نفسك مبرمجًا خلال يوم أو اثنين. لكن لا يزال عليك وضع الموقع الذي أنشأته على الويب، بمعنى أنك ستتعامل مع الخوادم وبروتوكولات نقل الملفات وصلاحيات مجلدات الجذر على الخادم. رغم أن المواقع الحالية أكثر تعقيدًا موازنةً بذلك الوقت إلا أن نشر موقعك بنفسك صار أسهل، وسيزداد سهولة عند استعمالك Git. أنشئ موقعًا باستعمال Hugo Hugo هو مولّد مواقع ساكنة (Static site generator) مفتوح المصدر. المواقع الساكنة هي ما كونت الإنترنت سابقًا (إذا عدنا بالزمن بعيدًا بما فيه الكفاية، لم يكن على الويب غيرها). هنالك عدة نقاط قوة لهذه المواقع الساكنة: من السهل إنشاؤها، فليس عليك كتابة نصوص برمجية. آمنة نسبيًا، إذ لا توجد شفرة برمجية لتنفيذها على الخادم. أيضًا هي سريعة على نحو عام لعدم الحاجة لعمليات حوسبة، فقط نقل محتوى الصفحة. Hugo ليس المولدّ الوحيد للمواقع الساكنة، يقدِّم Grav، وPico، وJekyll، وPodwrite وبرامج أخرى طرقًا سهلة لإنشاء مواقع إنترنت مكتملة الوظائف وبالكاد تتطلب أعمال صيانة. لكن Hugo لديه تكامل مع خدمات GitLab بشكل مدمج، أي يمكنك إنشاء واستضافة موقعك باستعمال حساب GitLab مجاني. أضف إلى ذلك امتلاك Hugo قاعدته الجماهيرية الخاصة، مثلا إنْ سبق واستعملت موقع Let's Encrypt فأنت بالفعل قد جربت موقعًا مبنيًا باستعمال Hugo. تثبيت Hugo يمكنك إيجاد إرشادات لتثبيت Hugo على أجهزة ماك، وويندوز، ولينكس وتوزيعات BSD، إذ يعدُّ عابرًا للمنصات. في حال استعمالك لإحدى توزيعات لينكس أو BSD، فالأسهل تثبيته من مستودع برمجيات أو شجرة منافذ. يختلف أمر التثبيت حسب ما توفّره توزيعتك. مثلاً على فيدورا يُكتب الأمر كالتالي: $ sudo dnf install hugo تأكد من أنك ثبته بطريقة صحيحة بتنفيذ الأمر التالي في سطر الأوامر: $ hugo help سيسرد لك هذا الأمر كل الخيارات المتاحة للأمر Hugo، وإذا لم يحدث ذلك فهذا يعني أنك ثبّته بطريقة خاطئة أو أنك بحاجة إلى إضافة الأمر إلى المتغير PATH. ابدأ بإنشاء موقعك لبناء موقع باستعمال Hugo، لابد من إنشاء بنية مجلدات بهيكلة خاصة، وهو ما يقوم به Hugo نيابة عنك عند تنفيذ الأمر التالي: $ hugo new site mysite هكذا أنشأت مجلّدًا باسم mysite يحوي جميع المجلدات الافتراضية اللازمة لبناء موقعك. ستستعمل Git كخادم لموقعك على الويب، لذلك انتقل إلى مجلد موقعك، الذي هو mysite في مثالنا، وقم بإعداده كمستودع Git مستعملًا الأوامر التالية: $ cd mysite $ git init كما أوضحنا سابقًا، Hugo متكامل مع خدمة Git، لذا يمكنك استعمال Git لتثبيت سمات لموقعك. إنْ لم تكن تخطّط لتطوير تصميم الموقع بنفسك، فيمكنك استعمال الخيار (depth--) لنسخ آخر إصدار من مصدر التصميم المختار كالتالي: $ git clone --depth 1 \ https://github.com/darshanbaral/mero.git\ theme/mero والآن لنُضف بعض المحتوى لموقعك: $ hugo new posts/hello.md استخدم محررك النصي المفضل لتعديل ملف hello.md على مسار content/posts. يقبل Hugo الملفات المرمزة بمارك داون ويحولها إلى منشورات بترميز HTML لذلك يفضل كتابة وتنسيق المحتوى بترميز markdown. إذا رغبت بإضافة الصور إلى منشوراتك، أنشئ مجلدًا باسم images في المسار الافتراضي. ضع جميع الصور بداخل هذا المجلد وقم بالإشارة إليها من ملف ماركداون مستعملًا المسار المطلق (Absolute path) أي بادئًا بمسار مجلد الصور (images/) كمثال:  اختر تصميمك يمكنك العثور على المزيد من القوالب في themes.gohugo.io، لكن يفضل استعمال التصميم الافتراضي أثناء فترة الاختبار. التصميم الأساسي لدى Hugo يسمى Ananke. بعض التصاميم لديها متطلبات معقدة وأخرى لا تقوم بتنسيق الصفحات بالشكل المتوقع بدون الدخول في ترتيبات متقدمة. تصميم Mero الذي سنستخدمه في المثال التالي يأتي ملحقًا بملف ضبط متخصص (config.toml)، ولكن بهدف التبسيط سنقتصر على ذكر الأساسيات فقط. افتح باستخدام محرر نصوص الملف config.toml وأضف خيارات الضبط التالية: languageCode = "en-us" title = "My website on the web" theme = "mero" [params] author = "Seth Kenlon" description = "My hugo demo" تحدّد الإعدادات أعلاه ترميز لغة الموقع (الإنكليزية الأمريكية en-us)، وعنوانه، والسمة المستخدمة، إضافة إلى اسم صاحب الموقع ووصفه. معاينة موقعك ليس عليك وضع أي شئ على الويب إلى أن تصبح جاهزًا لنشره. أثناء العمل يمكنك معاينة نسخة محلية من موقعك على خادم مدمج مع Hugo بتنفيذ الأمر التالي: $ hugo server --buildDrafts --disableFastRender أدخل العنوان http://localhost:1313 في متصفحك لتستعرض عملك الحالي. النشر على GitLab باستخدام Git لنشر واستضافة موقعك لدى GitLab، أنشئ مستودعًا لمحتوى موقعك. لإنشاء ذلك المستودع أضغط على زر إنشاء مشروع جديد (New Project) الموجود على صفحة مشاريع GitLab الخاصة بك، أنشئ مستودعًا فارغًا باسم (yourGitLabUsername.gitlab.io) مع إبدال yourGitLabUsername باسم المستخدم الخاص بحسابك على GitLab. من المهم استخدام هذا الاسم كاسم لمشروعك أيضًا ويمكنك لاحقًا تخصيص اسم نطاق لموقعك. لا تُضِف ترخيصًا أو ملف "اقرأني" (README). في البداية، تعقّد إضافة الملف إلى المستودعات المنشأة محليَّا من مهمة إرسال البيانات إلى GitLab. يمكنك إضافة تلك الملفات لاحقا. اضبط المستودع الفارغ على GitLab - بعد إنشائه - إلى إعدادات المجلّد الخاص بموقعك، وهو المجلّد الذي أعددناه سابقًا ليكون مستودع Git: $ git remote add origin git@gitlab.com:skenlon/mysite.git أنشئ ملفًا باسم gitlab-ci.yml لضبط إعدادات GitLab، وأدرج به الخيارات التالية: image: monachus/hugo variables: GIT_SUBMODULE_STRATEGY: recursive pages: script: - hugo artifacts: paths: - public only: - master يُعرِّف المعامل image حاوية الصور المستخدمة في موقعك. التعليمات الأخرى تمثّل في مجملها إرشادات لتهيئة خوادم GitLab للاستجابة بفعالية عندما ترسل شفرة مصدرية إلى مستودعك البعيد. اقرأ االتوثيق في القسم المختص على GitLab لمزيد من التفاصيل عن النشر والتكامل المستمرّيْن (CI/CD). تحديد الاستثناءات بوصولك لهذه النقطة تكون قد أعددت مستودع Git الخاص بموقعك والتعليمات البرمجية الخاصة بإنشاء موقعك على خادم GitLab، وموقعك أصبح جاهزًا للنشر. الآن قبل تنفيذ أي أمر من أوامر Git، تحتاج لتنفيذ بعض الإجراءات الاحترازية حتى لا يتحكّم Git في إصدارات ملفات لا ترغب في أن يتحكّم فيها. أولًا، أضف مسار (public/) الذي أنشأه Hugo مسبقًا عند إنشائه مشروع الموقع، أضفه إلى ملف (gitignore.). لست بحاجة لإدارة موقعك في شكله النهائي على Git، ما ستحتاجه هو تتبع التغييرات على الملفات المصدرية لمشروع Hugo. $ echo "/public" >> .gitignore أمر آخر، لا يمكن الحفاظ على مستودع Git داخل مستودع Git آخر إلّا باستخدام وحدة فرعية (Submodules). لتسهيل الأمور انقل المجلد git. من مجلّد السمات (themes) إلى مجلّد آخر ليبقى مجلد السمات خاصًّا بالتصميم فقط. $ mv themes/mero/.git ~/.local/share/Trash/files/ يمكنك استعمال سلة مهملات مثل Trashy بديلًا عن الأمر السابق: $ trash themes/mero/.git الجدير بالذكر أن عليك إضافة الملفات الخاصة بالتصميم الى مستودع Git حتى يتمكن GitLab من الوصول إلى تصاميمك، بدون ذلك لن تستطيع بناء الموقع بنجاح. هنا يمكنك إضافة جميع محتويات مشروعك من على مجلد جهازك ورفعها على GitLab: $ git add . $ git commit -m 'hugo init' $ git push -u origin HEAD انشر موقعك على الويب بعد أن رفعت جميع ملفات مشروعك إلى GitLab، انظر إلى الصفحة الخاصة بمشروعك. ستظهر أيقونة تشير أن GitLab يراجع ملفاتك، ربما يستغرق ذلك بضع دقائق لمعالجة ملفات مشروعك للمرة الأولى لذا تحلّ بالصبر. لكن لا تنتظر مدة طويلة جدًّا، فتحديث تلك الأيقونة لنفسها لا يُعتمد عليه. بينما تنتظر GitLab ليقوم بتجميع موقعك، اذهب لصفحة الضبط واعثر على لوحة التحكم بالصفحات (Pages). عندما يجهز موقعك ستُزوَّد برابط URL الخاص به. وكما أسلفنا سيكون العنوان مشابهًا للتالي (yourGitLabUsername.gitlab.io/yourProjectName). تصفح ذلك العنوان لترى ثمرة أعمالك. إذا حدث خطأ ما في تجميع الموقع، سيزودك GitLab بسجلات موقعك على قسم CI/CD. تصفح رسائل الخطأ لتحديد سبب المشكلة. Git والويب Hugo (أو Jekyll وغيره من الأدوات المشابهة لايتعدى كونه إحدى الطرق لاستعمال Git أدةً لنشر موقعك على الويب. يمكنك باستعمال خطافات Git على مستوى الخادم تصميم مسار لربط لمشروعك بالويب بأقل تدخل برمجي ممكن. يمكنك باستخدام النسخة المجتمعية (المجانية) من GitLab استضافة مشاريع GitLab على خادمك. كما يمكنك استخدام بدائل أخرى مثل Gitolite أو Gitea، واستعمال هذا المقال مصدرًا للإلهام بهدف إنشاء حلول خاصة بك. ترجمة -وبتصرف- للمقال Build and host a website with Git لصاحبه Seth Kenlon.

أحد أسوأ الأمور في موسم الأنفلونزا حتمية إصابتك بالمرض. فقد يأتي زملاء العمل وهم يعانون من رشح في الأنف. أو ربما تستقل الحافلة إلى مكان عمل مشترك، فيسعل ركاب آخرون ويلمسون نفس المَسند الذي تمسك به. أو ربما كنت تعمل من منزلك "الآمن" إلا أنه من المحتمل أن ينقل لك أطفالك جراثيم خطيرة تعرضوا لها في المدرسة. بغض النظر عن المكان الذي تذهب إليه أو من تكون محاطًا بهم فقد تشعر في بعض الأحيان أنه لا يوجد مكان آمن. ولكن هذا ما يحدث عندما تعمل وتعيش بالقرب من الآخرين. إذا كان شخص واحد مصابًا فانتشار المرض مسألة وقت فقط. الأمر نفسه ينطبق على التعرض لمخاطر الثغرات العابرة للمواقع (Cross-Site). من البديهي أن الأمن يشكل مصدر قلق كبير لكل من له علاقة بموقع ويب، سواء كان صاحب الموقع أو الشخص الذي يتسوق عليه أو المطور الذي قام بإنشائه. لذا، يبدو أن هناك خطرًا عند كل منعطف. لكن لنفترض أنك قررت اتخاذ القرار الاقتصادي والفعال بوضع عدة مواقع على شبكة واحدة (سواء كان ذلك من خلال استخدام ووردبريس مُتعدّد المواقع أو تشغيلها ببساطة من حساب الاستضافة نفسه). قد تؤدي ثغرة أمنية واحدة في واحد فقط من تلك المواقع إلى تعريض الشبكة بالكامل للخطر. يعد مقال أفضل ممارسات الأمان في ووردبريس جيدًا للبدء به، و لكنه قد لا يكون كافيا. إذا كنت تدير شبكة من مواقع ووردبريس جميعها من مكان واحد فهذا المنشور يناسبك. سأغطي بإيجاز المخاوف التي تتعلّق بالثغرات العابرة للمواقع Cross-Site، ثم أعرض قائمة مرجعية خاصة من النصائح لاستخدامها عند تشغيل شبكة من المواقع. من ينبغي أن يكون قلقًا بشأن مخاطر الثغرات العابرة للمواقع في ووردبريس؟ دعنا نواجه الأمر: يحتاج القراصنة هذه الأيام للمزيد من الإبداع في كيفية اختراق مواقع الويب. قد يكون الووردبريس هدفًا سهلاً بسبب شعبيته، ولكنه ليس منصة سهلة الاختراق إذا كان الأشخاص الذين يبنون ويديرون مواقع الويب يمتثلون لأفضل ممارسات الأمان. بالطبع يبدأ ذلك الالتزام بالتذبذب قليلاً مع تزايد عدد مواقع الويب على شبكتك. في ما يلي طرق يمكن بها تجميع مواقعك على الويب مما يعرضها عن غير قصد لمخاطر الثغرات العابرة للمواقع. ووردبريس مُتعدّد المواقع على الرغم من أن شبكة ووردبريس متعددة المواقع تعدّ ميزة رائعة لمطوري الويب الذين يرغبون في إدارة شبكة من المواقع بكل سهولة من خلال تثبيت واحد ووردبريس مرة واحدة فقط، إلّا أنها تعني أيضًا أن تفاحة فاسدة واحدة يمكن أن تفسد المجموعة بالكامل بسهولة. جوهر المسألة هو أنّ كل هذه الموارد المشتركة من ملفات، وملحقات، وبيانات الدخول، المخزَّنة في المكان نفسه تزيد من خطر أنّ أذية موقع ويب واحد يمكن أن تؤدّي إلى إصابة مواقع الشبكة كلها. حساب استضافة متعدد النطاقات ينطبق الأمر نفسه على مواقع الويب التي تشترك في حساب استضافة (ليس بالضرورة تلك الموجودة على استضافة مشتركة، بل فقط تلك المواقع التي تشترك في حساب واحد). كل ما يتطلبه الأمر هو موقع ويب واحد غير مؤمَّن على نحو سليم (من خلال ملحق سيئ أو كلمة مرور ضعيفة)، ويمكن بعد ذلك للمخترقين إحداث الفوضى في شبكة كاملة من المواقع. يوجد عدد من الأطراف التي من المحتمل أن تتأثر: الوكالات التي تريد إدارة جميع مواقع عملائها من حساب استضافة واحد، المطورين الذين يريدون أن يفعلوا الشيء نفسه، المطورين الذين يستخدمون حساب الاستضافة الخاص بهم لاختبار مواقع الويب وإعدادها، الشركات التي لديها عدد من مواقع الويب تحت مظلة علامتها التجارية الرئيسية وتريد الاحتفاظ بها جميعًا معا. إعادة بيع الاستضافة قد يجد مطورو الويب أن بيع الاستضافات، إما بدوام كامل أو تكملةً لعملهم اليومي، طريقة مربحة لكسب أموال إضافية باستخدام ووردبريس، وهو ما يعني أنك إذا لم تقم بتهيئة نظام الاستضافة الخاص بك بدقة فيمكنك أن تعرّض جميع مواقع عملائك للخطر. لا يمكنني التأكيد على الأمر بما فيه الكفاية: كل ما تتطلبه إصابة شبكة مواقع وتدميرها بالكامل هو إصابة موقع واحد منها. تخيل أثر ذلك، إنْ حدث، على عملك. أكدت للعملاء أنك ستهتم بمواقعهم على الويب، وتعتقد بصدق أن كل شيء سيكون على ما يرام. لكنّك تركت موقعًا مرحليًا غير مؤذٍ دون مراقبة، أو كنت تثق في أن عملاء الاستضافة سيؤمّنون مواقعهم الفردية على نحو صحيح … وحدث خطأ ما. إذن مالعمل الآن؟ حسنًا، أنت بحاجة إلى عدم الانتظار حتى "الآن.. ماذا نفعل؟". تحتاج إلى اتخاذ إجراء حاليًا لتأمين شبكة مواقع ووردبريس الخاصة بك على نحو صحيح من مخاطر الثغرات العابرة للمواقع. القائمة المرجعية: 8 أشياء تحتاج إلى القيام بها للتصدي للأضرار الناتجة عن الثغرات العابرة للمواقع من البديهي أنّ هذه القائمة ليست معدّة لتحل محل القائمة المرجعية لتأمين ووردبريس التي تعتمدها سلفا. تسري نصائح تلك القائمة سواء كنت تدير موقع ووردبريس واحدًا أو شبكة كاملة. ومع ذلك ينبغي أن تُضاف العناصر التالية إلى تلك القائمة المرجعيةإنْ كنت تنوي إدارة شبكة من المواقع. 1- فحص كل موقع الهدف من وراء جمع مواقع مختلفة في حساب استضافة مشترك واحد، أو إعداد ووردبريس مُتعدّد المواقع هو أن تتمكّن من إدارة المواقع في وقت واحد بصورة أكثر ملاءمة وفعالية. ومع ذلك، تبقى تلك المواقع ملكيات فريدة يجب التعامل معها على ذلك الأساس. لذا، بدلاً من افتراض أن إجراءات الأمان المستخدمة من قبل مزود الاستضافة، استخدم ملحقًا لفحص الأمان على كل موقع من مواقع ووردبريس الخاصة بك. يقوم ملحق Defender لأمن ووردبريس، بطبيعة الحال، بعمل رائع في فحص موقعك بانتظام، وفرض ممارسات أمنية صارمة، وتوثيق جميع الأنشطة، لذلك أقترح البدء به. 2- إضافة جدران نارية منفصلة تعلم أنك عندما تسجّل لدى مزوّد استضافة موثوق فإنه عادةً يروّج لوجود جدار ناري لحماية خوادمهم ومنع المخترقين. مع ذلك، إذا كنت تدير مواقع ووردبريس خاصة بك من حساب الاستضافة نفسه، فهذا يعني أن شبكتك مؤمنة من خلال جدار ناري واحد فقط، ولا يوجد حاجز منفصل يقف بين كل واحد من مواقعك مع البقية. بما أنّ سبب تأثير الثغرات العابرة للمواقع هو عدم وجود حواجز بين تلك المواقع، فمن المهم إضافة جدار ناري إلى كل موقع ويب. يؤّدي Cloudflare هذه المهمة بنجاح. يأتي جدار Cloudflare الناري لتطبيقات الويب مزودًا بقواعد مضمنة، ومن بينها قواعد تتصدّى للتهديدات والثغرات الخاصة بووردبريس. بمجرد تمكين جدار Cloudflare الناري لتطبيقات الويب فستطمئن لعلمك أن موقعك محمي من أحدث التهديدات. 3- استخدام ملحق موثوق لتعدّد مواقع ووردبريس إذا كانت الثغرة الأمنية في شبكة مواقعك ناتجة عن استخدام نظام ووردبريس مُتعدّد المواقع، فأفضل ما يمكنك فعله هو استخدام ملحق موثوق لهذا الغرض، مثل WP Ultimo. بهذه الطريقة تتيقّن أنْ تتحكّم أكثر في ما يفعله عملاؤك مع مواقعهم على الويب، وفي الوقت نفسه تتأكد أيضًا أن الملحق الذي تستخدمه غير خطر وآمن. 4- حجب السخام على شبكة مواقع ووردبريس بالطبع، لا تنسَ التعليقات غير المرغوب فيها، فهي أحد أهم الأسباب التي تجعل الكثير من المدونات والمواقع تقرر إيقاف التعليقات تماما. عندما تشغّل شبكة كبيرة من المواقع - خاصةً إذا كانت سيطرتك على محتوى المدونة أو التعليقات التي تظهر عليها ضئيلة أو معدومة - فأنت بحاجة إلى الملحق Akismet لكي يحمي مواقعك من السخام وحُقَن المحتوى الضارة الأخرى. 5 - تنظيف النطاقات القديمة كلما زادت شبكة مواقعك كلما أصبح من الأسهل فقدان أثر تلك المواقع. لهذا السبب يجب عليك تحديد موعد دوري - من الأفضل أن يكون كل مرة في الشهر أو في الأسبوع - لمراجعة حسابك على الاستضافة متعدّدة النطاقات، أو شبكة مواقع ووردبريس. يجب التخلص من أي نطاقات قديمة أو غير مستخدمة، ينطبق الأمر نفسه على مواقع الاختبار والتحضير. بمجرد إتاحة موقع ووردبريس العموم تصبح هذه المواقع غير ذات فائدة، إذا واجهت أي مواقع لم يتم تحديثها منذ عام فاستفسر من مالك الموقع لمعرفة ما إذا كان لا يزال بحاجة إلى الاستضافة. من خلال الحفاظ على خادمك خاليًّا من النطاقات القديمة فستقلّل من احتمال أن يصادفها القراصنة ويستفيدوا من البيئة الممهدة المثالية المتمثّلة في الأنشطة غير الخاضعة للرقابة، وبرنامج ووردبريس وملحقاته غير المحدثة، وما إلى ذلك. 6- الحفاظ على الإضافات والسمات محدثة إنْ كنت تمضي وقتًا طويلًا في مستودع ملحقات ووردبريس فستتعرّف على هذه الرسالة. إذا كنت تجمع مواقع ويب في بيئة ووردبريس متعدّدة المواقع أو في حساب الاستضافة نفسه، فنرجو أن تكون لديك مجموعة الملحقات والسمات الموثوقة نفسها على جميع مواقعك. على الرغم من أن بيئة ووردبريس متعدّدة المواقع تبسط عملية الحفاظ على الملحقات والسمات "المشتركة" محدَّثة عبر جميع المواقع، إلّا أن ذلك لا يقلّل من أهميّة المراجعة المنتظمة لكل تكامل مع خدمات طرف ثالث. قد لا تعرف أبدًا متى يقرر مطوّر إيقاف دعم خدمة، أو متى توضع إشارة تحذير على ملحق في مستودع ووردبريس، أو متى تظهر ثغرة أمنية جديدة في أحد هذه البرامج. مع ذلك، تجد أحيانًا عناءً كبيرًا في المواكبة المستمرة لجميع تحديثات ووردبريس، وكذلك الملحقات والسمات التي لا تعد ولا تحصى؛ وهو ما يجعل من ملحق أو برنامج يحدّث تلقائيًا الملحقات والسمات أمرًا مفيدًا للغاية. يتمتع أعضاء WPMU DEV، على سبيل المثال، بميزة التحديثات التلقائية التي تشغّل التحديثات وتأخذ نسخًا احتياطية تلقائيّا. 7- تهيئة الخادم بطريقة صحيحة سواء تعلّق الأمر بيئة ووردبريس متعدّدة المواقع أو حساب استضافة مشترك فإن الحفاظ على أمان المواقع يتطلّب إدارة إعدادات الشبكة بذكاء. في ما يلي نصائح بسيطة لمساعدتك في القيام بذلك: إنشاء حسابات منفصلة لمنصات مواقع الويب: إذا قمت بإنشاء مواقع ويب باستخدام منصات أخرى غير ووردبريس، فيجب أن تكون لديك حسابات منفصلة لمواقع ووردبريس، ومواقع دروبال، ومواقع جوملا وغيرها. تجنب خلط الحابل بالنابل في وظائف المضيف: نعني بذلك نوعية الاستضافة. لذا، إذا كنت تعمل في بيع استضافة مواقع الويب فقد تزود العملاء أيضًا باستضافة البريد الإلكتروني. لا تخلط بين تلك الوظائف، وأبق كلّ واحدة منها منفصلة عن الأخرى. افصل بين مواقع الويب التجريبية ومواقع الويب المتاحة للعموم: على الرغم من أنك قد تميل لوضع مواقع ما زالت في مراحل التطوير والاختبار على نفس الحساب مع تلك المتاحة للعموم، إلّا أنه من الأفضل ألّا تفعل ذلك. سيكون الفصل بينها أكثر أمانًا، خاصة إذا لم تكن جيدًا في استحضار حذف مواقع أو التحضير بعد الانتهاء منها. والأفضل من ذلك أن تفصل بين الأدوات التي تستخدمها للاختبار وتلك التي تستخدمها للتحضير، حتى تتمكن من تجنب هذه المشكلة تماما. 8- استخدام مضيف موثوق في نهاية المطاف يعتمد أمان مواقع الويب الخاصة بك على مدى تأمين كل واحد على حدة. مع ذلك إذا لم تبدأ بمضيف موثوق يوفر لك خوادم آمنة ومُعدة بطريقة صحيحة فربما تواجه مشاكل على المدى الطويل. يشيع ذلك في الحالات التي لا تتبع أفضل الممارسات لتأمين كل موقع، والحفاظ على المستخدمين محجوزين في مواقعهم الخاصة. بالطبع إذا استمررت في القلق بشأن إصابة المواقع في شبكتك فيمكنك دائمًا استضافة كل موقع على حدة باستخدام طريقة أكثر أمانًا وعزلًا، مثل الخادم الافتراضي الخاص أو استضافة خادم مخصص. على الرغم من أن تلك الطرق تلغي الحاجة لإنشاء شبكة متعددة المواقع فإنها تجنبك احتمالية الإصابة بالثغرات العابرة للمواقع. في الختام كل ما يتطلبه الأمر تفاحة واحدة فاسدة لتدمير الباقي. أحيانًا يكون من الصعب رؤية تلك التفاحة الفاسدة عندما يكون لديك الكثير من التفاح لمراقبته، لهذا السبب تجب حماية كل موقع في شبكتك. إذا كان موقع ما لا يهمك بما يكفي للاهتمام بحمايته فيجب ألا يكون ضمن بيئة ووردبريس مُتعدّدة المواقع، أو يتشارك مساحة على حساب الاستضافة مع مواقعك الأخرى. الأمر بسيط. عليك الالتزام بالنصائح المذكورة أعلاه وستكون قادرًا على تشديد أمان شبكتك بدرجة تكفي لكي لا تقلق بعد الآن بشأن الثغرات العابرة للمواقع. ترجمة -وبتصرف- للمقال The Dangers of Cross-Site Contamination and How to Prevent It لصاحبته Suzanne Scacca