כתובת CiviCRM אחת למשתמשי משרד ו-VPN: שלבי ההגדרה

מחשב נייד במשרד אמור לפתוח את אותה סימנייה של CiviCRM ליד השולחן ושוב מהבית דרך ה-VPN. העיצוב ששורד מפגש עם משתמשים הוא כתובת קנונית אחת, נניח https://crm.example.org/, עם נתיב רשת מאושר מכל מיקום ותעודה תקפה לאותו שם. ה-VPN משנה כיצד לקוח מרוחק מגיע לשרת. הוא לעולם לא אמור לשנות את זהות האפליקציה, כי ברגע שהוא עושה זאת, כל קישור נוצר, הפניה וקריאה חוזרת של אינטגרציה הופכים לבעיה שנייה שצריך לפתור.

בחרו את הכתובת לפני שתבחרו את המסלול

רשמו תחילה את הכתובת המיועדת, כולל כל רכיב נתיב שה-CMS זקוק לו, והתייחסו אליה כאל נקודת העוגן. כל השאר במדריך הזה הוא פרט יישום שיכול להשתנות בלי לגעת בה: איזו תשובת DNS מקבלת כל קבוצה, איזה כלל חומת אש מתיר למאזין, וכן האם התעבורה מגיעה דרך מנהרה או דרך יציאת מתג מקומית.

רשמו ארבעה ערכים יחד בתוכנית הגישה, כי הם עובדים רק כקבוצה. הכתובת הקנונית. התשובה שכל קבוצת לקוחות אמורה לקבל עבור אותו שם. המסלול וכלל הגישה עבור אותה תשובה. שם המארח ששרת האינטרנט והתעודה מוגדרים לשרת. כשמשהו יישבר בהמשך, הרכיב השבור הוא אחד מאותם ארבעה, ותדעו איזה מהם שיניתם.

שלב 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

המאזין חייב להיות מוגדר לשרת את השם הקנוני, והתעודה חייבת לכסות אותו. גלישה לפי הכתובת הגולמית אינה פתרון: היא יוצרת אי-התאמה בשם, עלולה לשבור את היקף קובצי ה-Cookie, ומלמדת משתמשים לעבור אזהרות שתצטרכו להסביר בהמשך למבקר.

מאחורי פרוקסי הפוך, ודאו שהאפליקציה יודעת שהבקשה הגיעה ב-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. עברו על כתובות המשאבים, המטמונים, הקישורים שפורסמו וכל אינטגרציה חיצונית ששומרת את הכתובת הישנה, ואז עדכנו אותם בחלון אחד כדי שאיש לא יישאר עם סימנייה שהועברה למחצה.

שם מארח של בקשה אינו החלטת אמון

אל תבחרו כתובת בסיס מורשית כי כותרת בקשה מכילה מחרוזת מסוימת. PHP מתעד תצורות Apache שבהן ערך שם השרת יכול לשקף מארח שסיפק הלקוח, ומשתנה כתובת השרת מתאר את השרת, לא את מיקום המבקר. אף אחד מאלה אינו מנגנון בקרת גישה, ובנייה של אחד מהם היא הדרך שבה שירות פרטי מגיע לשרת תוכן שגוי למארח שגוי.

אם באמת נדרשים כמה שמות מארח, הגדירו רשימת היתר מפורשת בשרת האינטרנט, ב-CMS ובשכבת האפליקציה, ותנו לשם המארח של הבקשה לבחור רק מבין ערכים מאושרים. קלט שרירותי לעולם לא אמור להפוך למקור של קישורים מוחלטים או ליעד הפניה מהימן.

סיימו עם אותה סימנייה בכל הקשר מאושר: התחברות, ניווט פנימי רגיל ובקשת משאב אחת. השוו את שמות המארח בתגובות, לא רק אם העמוד נטען. בדיקת שלוש הבקשות הזו מפרידה בין בעיית מסלול לבין אפליקציה שעדיין יוצרת את הכתובת השגויה, והיא אורכת כבדקה לכל קבוצת לקוחות.