یک نشانی CiviCRM برای کاربران دفتر و VPN: مراحل راه‌اندازی

لپ‌تاپ اداری باید همان نشانک CiviCRM را پشت میز و دوباره از خانه از طریق VPN باز کند. طراحی‌ای که در برخورد با کاربران دوام می‌آورد یک نشانی متعارف است، مثلاً https://crm.example.org/، با مسیر شبکه تأییدشده از هر مکان و گواهی‌نامه‌ای که برای آن نام معتبر باشد. VPN تغییر می‌دهد که کارخواه راه‌دور چگونه به کارساز می‌رسد. هرگز نباید هویت برنامه را تغییر دهد، زیرا در همان لحظه‌ای که این کار را بکند، هر پیوند تولیدشده، تغییرمسیر و فراخوان بازگشت یکپارچه‌سازی به مسئله دومی برای حل تبدیل می‌شود.

پیش از انتخاب مسیر، نشانی URL را انتخاب کنید

ابتدا نشانی موردنظر را بنویسید، با در نظر گرفتن هر مؤلفه مسیری که CMS نیاز دارد، و آن را نقطه ثابت بدانید. هر چیز دیگری در این راهنما جزئیات پیاده‌سازی است که می‌تواند بدون دست زدن به آن تغییر کند: هر گروه چه پاسخ DNS می‌گیرد، کدام قاعده دیوار آتش به شنونده اجازه می‌دهد، و اینکه ترافیک از طریق تونل می‌آید یا از درگاه سوئیچ محلی.

چهار مقدار را با هم در طرح دسترسی ثبت کنید، زیرا فقط به‌صورت یک مجموعه کار می‌کنند. نشانی URL متعارف. پاسخی که هر گروه کارخواه باید برای آن نام دریافت کند. مسیر و قاعده دسترسی برای آن پاسخ. نام میزبانی که کارساز وب و گواهی‌نامه برای ارائه آن پیکربندی شده‌اند. وقتی بعداً چیزی خراب شود، عنصر خراب یکی از آن چهار مورد است و می‌دانید کدام را تغییر داده‌اید.

گام 1: کاری کنید نام برای هر دو گروه درست تفکیک شود

هر دو گروه باید پاسخی خصوصی بگیرند که واقعاً بتوانند به آن برسند، و تفاوت پاسخ‌ها مشروع است تا زمانی که نام تفاوت نداشته باشد. کارخواه‌های LAN از طریق تفکیک‌کننده داخلی تفکیک می‌کنند؛ کارخواه‌های 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 رسیده است. بیشتر سکوهای CMS پیوندهای مطلق را از طرح‌واره تشخیص‌داده‌شده تولید می‌کنند، و پیشکاری که 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 درون یک CMS اجرا می‌شود و صفحه‌هایی که اهمیت دارند آن‌هایی هستند که URLهای خود را می‌سازند: تغییرمسیر ورود، منوی مدیریت، منابع افزونه‌ها، پیوندهای فایل‌های بارگذاری‌شده و هر فراخوان بازگشت خارجی که یکپارچه‌سازی ثبت می‌کند.

داشبورد را بارگذاری کنید، یک رکورد مخاطب باز کنید و منبع صفحه را برای پیوندهای مطلق ببینید. اگر به نام میزبانی اشاره کنند که فقط یک گروه کارخواه می‌تواند به آن برسد، نشانی پایه هنوز اشتباه است هرچند صفحه نمایش داده شده. اگر به نام درست اما طرح‌واره اشتباه اشاره کنند، پیکربندی پیشکار چیزی است که باید درست شود.

جایی که نشانی واقعاً باید تغییر کند، آن را به‌عنوان مهاجرت برنامه در نظر بگیرید نه ویرایش DNS. URLهای منابع، حافظه‌های نهان، پیوندهای منتشرشده و هر یکپارچه‌سازی خارجی که نشانی قدیمی را ذخیره می‌کند بررسی کنید، سپس آن‌ها را در یک پنجره به‌روزرسانی کنید تا هیچ‌کس نشانکی نیمه‌مهاجرت‌شده نداشته باشد.

نام میزبان درخواست تصمیم اعتماد نیست

نشانی پایه ممتاز را به این دلیل انتخاب نکنید که یک سرآیه درخواست رشته خاصی دارد. PHP پیکربندی‌هایی از Apache را مستند می‌کند که در آن‌ها مقدار نام کارساز می‌تواند میزبانی را که کارخواه ارائه داده بازتاب دهد، و متغیر نشانی کارساز خود کارساز را توصیف می‌کند نه مکان بازدیدکننده را. هیچ‌یک از این‌ها سازوکار کنترل دسترسی نیست و ساختن یکی از آن‌ها همان راهی است که یک سرویس خصوصی در نهایت محتوای اشتباه را به میزبان اشتباه ارائه می‌کند.

اگر واقعاً چند نام میزبان لازم است، فهرست مجاز صریحی در کارساز وب، CMS و لایه برنامه پیکربندی کنید و بگذارید نام میزبان درخواست فقط از میان ورودی‌های تأییدشده انتخاب کند. ورودی دلخواه هرگز نباید منبع پیوندهای مطلق یا مقصد تغییرمسیر مورد اعتماد شود.

با همان نشانک در هر زمینه تأییدشده تمام کنید: یک ورود، یک پیمایش داخلی معمول و یک درخواست منبع. نام میزبان‌ها را در پاسخ‌ها مقایسه کنید، نه فقط اینکه صفحه بارگذاری شده است. این بررسی سه‌درخواستی مسئله مسیر را از برنامه‌ای که هنوز نشانی اشتباه تولید می‌کند جدا می‌کند و برای هر گروه کارخواه حدود یک دقیقه طول می‌کشد.