عنوان CiviCRM واحد لمستخدمي المكتب وVPN: خطوات الإعداد

من المفترض أن يفتح حاسوب المكتب الإشارة المرجعية نفسها لـ CiviCRM على مكتبه ومرة أخرى من المنزل عبر VPN. التصميم الذي يصمد أمام الاستخدام الفعلي هو عنوان أساسي واحد، لنقل https://crm.example.org/، مع مسار شبكة معتمد من كل موقع، وشهادة صالحة لذلك الاسم. يغيّر VPN طريقة وصول العميل البعيد إلى الخادم. ولا ينبغي أن يغيّر هوية التطبيق أبداً، لأنه في اللحظة التي يفعل فيها ذلك يصبح كل رابط مُنشأ وإعادة توجيه واستدعاء تكامل مشكلة ثانية يجب حلها.

اختر عنوان URL قبل أن تختار المسار

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

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

الخطوة 1: اجعل الاسم يُحلّ بشكل صحيح لكلا الفريقين

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

اختبر الاسم من كل سياق بدلاً من افتراضه، واختبر المسار بشكل مستقل عن DNS باستخدام خيار resolve في curl، الذي يثبّت العنوان لطلب واحد:

dig +short crm.example.org
curl -sSI --resolve crm.example.org:443:10.10.5.20 https://crm.example.org/ | head -5

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

الخطوة 2: وحّد خادم الويب والشهادة وعنوان أساس CMS

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

خلف وكيل عكسي، تأكد من أن التطبيق يعرف أن الطلب وصل عبر HTTPS. تُنشئ معظم أنظمة إدارة المحتوى روابط مطلقة من البروتوكول المكتشف، والوكيل الذي ينهي TLS دون تمرير البروتوكول الأصلي ينتج صفحة مليئة بموارد http:// قد يحظرها المتصفح. هيّئ الوكيل الموثوق والترويسات المُمرَّرة بشكل صريح بدلاً من ترك التطبيق يخمّن.

ثم وحّد عنوان أساس CMS وCiviCRM. يحتفظ CiviCRM بعنوان الأساس المحدد له ويعرض طريقة مدعومة لإعادة حسابه: إجراء Cleanup Caches and Update Paths الإداري، الموثق في دليل استكشاف أخطاء تثبيت CiviCRM وإصلاحها. شغّله بعد اتفاق الاسم الأساسي وإعداد CMS، وليس قبله، وإلا فستخزّن مؤقتاً قيمة أنت على وشك تغييرها.

cv flush
# then Administer > System Settings > Cleanup Caches and Update Paths

الخطوة 3: افحص العناوين التي يولّدها CiviCRM

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

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

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

اسم مضيف الطلب ليس قرار ثقة

لا تختر عنوان أساس مميزاً لأن ترويسة طلب تحتوي على سلسلة معينة. يوثّق PHP تهيئات Apache التي يمكن فيها أن تعكس قيمة اسم الخادم مضيفاً يوفره العميل، كما أن متغير عنوان الخادم يصف الخادم لا موقع الزائر. لا هذا ولا ذاك آلية تحكم في الوصول، وبناء واحدة منهما هو الطريقة التي تنتهي بها خدمة خاصة إلى تقديم المحتوى الخطأ للمضيف الخطأ.

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

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