اسأل النادل: هل من المقبول توفير بيانات اعتماد مسؤول WordPress لفريق دعم البرنامج المساعد؟

لا يا ندى. ناه. لا. هذا سلبي. تحت أي ظرف من الظروف. أمي لم تربي أي أحمق. هيك ناو. ليس فى حياتك. والآلاف من الطرق الأخرى لإخبار أي شخص يطلب بيانات اعتماد الموقع أن يخطئ ، حتى موظفي دعم الإضافات في شركة تطوير WordPress "موثوقة".

هذه طريقتي في القول إنني لا أثق بأحد. ولا يجب عليك. ومع ذلك ، هناك حالات يكون من الضروري فيها توفير أذونات المسؤول لفريق دعم المكون الإضافي.

تأتي الدفعة الحالية من سلسلة Ask the Bartender مقدمة من قارئ يُدعى نيكو. نظرًا لأن النص بالكامل يزيد عن 1000 كلمة ، سأقوم ببساطة بالربط إلى النص عبر ملف .txt لأولئك الذين يرغبون في قراءته بالكامل. هنا في المنشور ، سألتزم بالأجزاء الحيوية. أو على الأقل الأجزاء التي أريد معالجتها.

بدأ أحد أعضاء مجموعة نيكو على Facebook المناقشة.

هل من المقبول إرسال تفاصيل FTP لمطور البرنامج المساعد لاستكشاف المشكلة التي نواجهها مع WooCommerce. لقد قدمنا ​​بالفعل بيانات اعتماد مسؤول WordPress.

هذه ممارسة عادية جدًا في عالم WordPress ، أليس كذلك؟ يساعد مطورو المكونات الإضافية في حل المشكلات ، وإذا لم يتمكنوا من تكرار مشكلة ، فهم بحاجة إلى الوصول حتى يتمكنوا من التحقق مما إذا كانت مشكلة مكون إضافي أو مشكلة في الخادم وإصلاح الأشياء؟

على مر السنين ، رأيت أن هذا أصبح أكثر شيوعًا. ومع ذلك ، فهي ليست ممارسة أوصي بها من جانب المستخدم أو المطور. يجب على أي مالك موقع أن يسأل عما إذا كان يثق في الشخص الذي يمنح أوراق اعتماده. إذا كانت الإجابة على هذا السؤال بالنفي ، فلديك إجابة على السؤال الأول.

خلال أكثر من عقد من تشغيل متجر السمات والمكونات الإضافية ، لم أحتاج مطلقًا إلى وصول المسؤول أو FTP للتعامل مع سؤال الدعم. لا يهم ما إذا كان مكونًا إضافيًا كبيرًا ومعقدًا أم صغيرًا. نظرًا لأنني كنت الشخص الوحيد في الشركة ، فقد أجبت شخصيًا أيضًا على مئات الآلاف من أسئلة الدعم على مر السنين. ومع ذلك ، لم أقم بتسجيل الدخول مرة واحدة إلى موقع المستخدم لمساعدتهم. كان هذا يبدو دائمًا وكأنه مشكلة تتعلق بالمسؤولية بالنسبة لي ، لكنني أيضًا استخدمت مثل هذه السيناريوهات مثل لحظات التدريس حول الثقة والأمان.

قدم المستخدمون أوراق اعتماد لي أحيانًا دون أن أسألهم. غالبًا ما ينشرونها بنص عادي في المنتديات أو البريد الإلكتروني أو Slack (أيضًا ، يجب ألا تفعل ذلك أبدًا). إذا احتاجت الشفرة الموجودة في الموقع إلى التغيير ، فقد قام المستخدمون بتنفيذ المهمة بأنفسهم أو قاموا بتثبيت إصدار خالٍ من الأخطاء من السمة / المكون الإضافي الذي قمت بتسليمه.

إذا لم يعرفوا كيفية أداء مهمة ما عبر المسؤول أو FTP أو غير ذلك ، فقد استغرقت وقتًا لتعليمهم. نعم ، لقد تطلب ذلك مزيدًا من الطاقة من كلا الطرفين ، لكنني أعتقد أننا كنا الأفضل لذلك. أكثر من مرة ، قادت تلك اللحظات بعض المستخدمين إلى طريق أن يصبحوا مطورين بأنفسهم ، أو كانت على الأقل نقطة انطلاق صغيرة بالنسبة لهم. ما زلت أصدقاء مع العديد منهم اليوم وأنا فخور بأنهم بدأوا مع متجر WordPress الصغير الخاص بي.

كانت بعض الحالات أقسى من غيرها. في كثير من الأحيان ، كنت أقوم بتكرار إعدادهم (المكونات الإضافية ، والقوالب ، وما إلى ذلك) على جهازي. قادني هذا في معظم الأوقات إلى الحل - كنت أستخدم __doing_it_wrong() قبل فترة طويلة من تقديم WordPress للفكرة. على المدى الطويل ، تمكنت من تمرير عدد لا يحصى من إصلاحات الأخطاء إلى المطورين الآخرين. لقد كونت الكثير من أصدقاء المطورين بهذه الطريقة أيضًا.

ليس لدي شك في أن الطريق الذي سلكته كان أطول من الاثنين. كانت هناك أوقات قضيت فيها ساعة أو ساعتين أو حتى أكثر في تلبية احتياجات مستخدم واحد. إن الظهور في بعض مسؤولي WordPress الخاص بهم سيكون بمثابة دورة أسرع.

ومع ذلك ، لم يكن مستخدمو السمة والمكونات الإضافية بحاجة إلى القلق بشأن ما إذا كانوا يثقون بي بدرجة كافية لتوفير هذا المستوى من الوصول. بالإضافة إلى ذلك ، لم تتح لي فرصة كسر موقعهم عن طريق الخطأ عن طريق إجراء تغييرات مخصصة.

هل هناك أوقات يحتاج فيها فريق دعم المكون الإضافي حقًا إلى الوصول؟ من المحتمل.

كان السؤال الأصلي يتعلق بـ WooCommerce. إنها واحدة من أكثر المكونات الإضافية تقدمًا من الناحية الفنية في WordPress. يعد تكرار إعداد المستخدم خارج الموقع أصعب من معظم الآخرين. قد تكون هناك أوقات نادرة تحتاج فيها إلى توفير بعض الوصول ، ولكن يجب ألا تثق في أي شخص أبدًا.

يدور الجزء الثاني من سؤال نيكو حول اللائحة العامة لحماية البيانات (GDPR) للاتحاد الأوروبي وبيانات المستخدم. إنه جزء حيوي من التعامل مع تلك الأوقات التي تقرر فيها تسليم مفاتيح موقع الويب الخاص بك.

حسنًا ، هنا تأتي المشكلة بعد أن نفكر في الناتج المحلي الإجمالي. إذا حدث أن يكون هذا المطور خارج الاتحاد الأوروبي ، فستحتاج إلى إخفاء هوية بيانات العميل وإبرام اتفاقية NDA مع هذا المطور أو الشركة التي تقف وراء المكون الإضافي حتى يتمكنوا من الوصول وإصلاح الأشياء.

سأقدم هذا بالعادة أنا لست محاميًا . ومع ذلك ، تعد حماية بيانات المستخدم دائمًا أولوية قانونية وأخلاقية على أي موقع تديره ، بغض النظر عن الاختصاص القضائي الذي تخضع له.

في تلك الحالات - مرة أخرى ، النادرة - حيث تحتاج إلى توفير الوصول إلى مسؤول WordPress الخاص بك ، هناك خطوات يمكنك اتخاذها لحماية موقعك وبياناته بشكل أفضل. بغض النظر عن مصداقية المطور أو أحد موظفي الدعم ، هناك دائمًا قاعدة عامة واحدة عند التعامل مع أمان موقع الويب: لا تثق بأحد ولا تثق بأي شيء.

يجب أن تكون الخطوة الأولى دائمًا هي وجود نظام نسخ احتياطي. إذا كسر فريق الدعم شيئًا ما ، فستحتاج إلى إعادة الموقع إلى حالته السابقة.

لا تقدم مطلقًا وصولاً كاملاً على مستوى المسؤول. أوصي بتثبيت وتفعيل مكون إضافي لإدارة الدور والقدرات. سيسمح لك ذلك بإنشاء دور مخصص لمساعدة الدعم والحد من مناطق الموقع التي يمكنهم الوصول إليها. يمكنك بعد ذلك إنشاء حساب مستخدم لهم بهذا الدور. بمجرد الانتهاء من عملهم ، احذف حسابهم.

إذا كنت لا تريد منهم رؤية المستخدمين المسجلين أو القيام بأي شيء باستخدام بيانات المستخدم على الإطلاق ، فتأكد من أن دور المستخدم الخاص بهم لا يحتوي على القدرات التالية:

• create_users
• delete_users
• edit_users
• list_users
• promote_users
• remove_users

هناك العديد من الإمكانات الأخرى على مستوى المسؤول ، مثل edit_files و edit_plugins و edit_themes والتي يجب عليك أيضًا تجنبها. بشكل أساسي ، عدم السماح بمعظم الأحرف الاستهلالية من قائمة المسؤولين في وثائق WordPress.

على الأرجح ، قد تحتاج فرق المكونات الإضافية إلى الوصول إلى إمكانية إدارة manage_options وأي منها مخصص للمكون الإضافي الخاص بهم. حتى تلك الأشياء يمكن أن تكون خطيرة ، ولكن يجب أن تخفف تلك النسخة الاحتياطية التي تضعها من أي مشكلات محتملة.

بالنسبة لكلمة مرور FTP؟ أثق في عدد قليل جدًا من الأشخاص الذين يتمتعون بهذا المستوى من الوصول.

ربما يبدو هذا الرد وكأنني لا أعتقد أن أي متاجر أو مطورين إضافيين جديرين بالثقة. بصراحة ، لا أعرف أي شيء قد خرق ثقة المستخدم باستخدام بيانات اعتماد تسجيل الدخول أو FTP بهذه الطريقة. من ناحية أخرى ، ليس لدي أي طريقة لمعرفة ما إذا كان الموظف الذي أتحدث إليه يخطط للغضب من وظيفته في فترة ما بعد الظهر وهو على استعداد لإحراق كل شيء في الصباح.

لقد رأيت أيضًا عددًا قليلاً من الحالات التي تدخل فيها مطور لإصلاح شيء ما ولكن انتهى به الأمر إلى كسر الموقع على طول الطريق. كانت النسخ الاحتياطية حاسمة في معالجة هذه القضايا.

لا يهدف هذا المنشور إلى جعل مطوري البرامج الإضافية أو الشركات تبدو غير جديرة بالثقة. معظمهم أناس طيبون يحاولون فقط كسب العيش بصدق. ومع ذلك ، فإن عدم الوثوق بأي شيء هو أمان موقع الويب 101. إنه مجرد الأساس الذي يجب أن يعمل به المستخدمون. إذا دخلت في أي تفاعل مع هذه العقلية ، فيجب أن تساعدك على اتخاذ قرارات أكثر ذكاءً على أساس كل حالة على حدة.