دفتری اور VPN صارفین کے لیے ایک CiviCRM URL: سیٹ اپ کے مراحل

دفتر کا لیپ ٹاپ اپنی میز پر اور پھر گھر سے VPN کے ذریعے وہی CiviCRM بک مارک کھولے۔ وہ ڈیزائن جو صارفین کے ساتھ رابطے میں قائم رہتا ہے ایک ہی کینونیکل پتہ ہے، فرض کریں https://crm.example.org/, جس کے ساتھ ہر مقام سے منظور شدہ نیٹ ورک راستہ اور اس نام کے لیے درست سرٹیفکیٹ ہو۔ VPN بدلتا ہے کہ ایک دور دراز کلائنٹ سرور تک کیسے پہنچتا ہے۔ اسے کبھی ایپلیکیشن کی شناخت نہیں بدلنی چاہیے، کیونکہ جس لمحے یہ بدلتا ہے، ہر بنایا گیا لنک، ری ڈائریکٹ اور انٹیگریشن کال بیک حل کرنے والا دوسرا مسئلہ بن جاتا ہے۔

راستہ چننے سے پہلے URL چنیں

پہلے مطلوبہ پتہ لکھیں، بشمول کوئی بھی راستہ جزو جس کی CMS کو ضرورت ہو، اور اسے مقررہ نقطہ سمجھیں۔ اس رہنما میں باقی سب کچھ عمل درآمد کی تفصیل ہے جو اسے چھوئے بغیر بدلی جا سکتی ہے: ہر گروپ کو کون سا DNS جواب ملتا ہے، کون سا فائر وال قاعدہ سننے والے کو اجازت دیتا ہے، اور آیا ٹریفک سرنگ کے ذریعے آتی ہے یا مقامی سوئچ پورٹ کے ذریعے۔

رسائی کے منصوبے میں چار قدریں اکٹھی درج کریں، کیونکہ وہ صرف ایک مجموعے کے طور پر کام کرتی ہیں۔ کینونیکل URL۔ وہ جواب جو ہر کلائنٹ گروپ کو اس نام کے لیے ملنا چاہیے۔ اس جواب کے لیے راستہ اور رسائی قاعدہ۔ وہ ہوسٹ نام جس کی خدمت کے لیے ویب سرور اور سرٹیفکیٹ ترتیب دیے گئے ہیں۔ جب بعد میں کچھ خراب ہو، خراب عنصر ان چار میں سے ایک ہوتا ہے، اور آپ کو معلوم ہوگا کہ آپ نے کون سا بدلا۔

مرحلہ 1: یقینی بنائیں کہ نام دونوں گروپوں کے لیے درست طریقے سے حل ہو

دونوں گروپوں کو ایک نجی جواب ملنا چاہیے جس تک وہ واقعی پہنچ سکیں، اور یہ جائز ہے کہ جواب مختلف ہوں جب تک نام مختلف نہ ہو۔ LAN کلائنٹ اندرونی حل کنندہ کے ذریعے حل کرتے ہیں؛ VPN کلائنٹس کو ایسی حل کنندہ پالیسی چاہیے جو انہیں وہی زون دے، بجائے اس کے کہ استفسار عوامی حل کنندہ تک لیک ہو اور انہیں ایسا عوامی جواب ملے جو وہ استعمال نہ کر سکیں۔

فرض کرنے کے بجائے ہر سیاق سے نام جانچیں، اور curl کے resolve اختیار کے ساتھ DNS سے آزاد راستہ جانچیں، جو ایک درخواست کے لیے پتہ مقرر کرتا ہے:

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 بنیادی URL کو ہم آہنگ کریں

سننے والا کینونیکل نام کی خدمت کے لیے ترتیب دیا گیا ہونا چاہیے، اور سرٹیفکیٹ اسے ڈھانپنا چاہیے۔ خام پتے سے براؤز کرنا کوئی حل نہیں: یہ نام کی عدم مطابقت پیدا کرتا ہے، کوکی کی حد توڑ سکتا ہے، اور صارفین کو ان انتباہات سے گزرنا سکھاتا ہے جن کی وضاحت آپ کو بعد میں آڈیٹر کو کرنی ہوگی۔

ریورس پراکسی کے پیچھے، یقینی بنائیں کہ ایپلیکیشن کو معلوم ہے کہ درخواست HTTPS کے ذریعے آئی ہے۔ زیادہ تر CMS پلیٹ فارم دریافت شدہ اسکیم سے مطلق لنک بناتے ہیں، اور ایسی پراکسی جو اصل اسکیم آگے بھیجے بغیر TLS ختم کرے http:// ایسے وسائل سے بھرا صفحہ بناتی ہے جنہیں براؤزر روک سکتا ہے۔ ایپلیکیشن کو اندازہ لگانے دینے کے بجائے قابل اعتماد پراکسی اور آگے بھیجے گئے ہیڈر واضح طور پر ترتیب دیں۔

پھر CMS اور CiviCRM بنیادی URL ہم آہنگ کریں۔ CiviCRM اپنا متعین بنیادی URL رکھتا ہے اور اسے دوبارہ شمار کرنے کا معاون طریقہ پیش کرتا ہے: 'کیش صاف کریں اور راستے اپ ڈیٹ کریں' انتظامی عمل، جو یہاں دستاویزی ہے CiviCRM انسٹالیشن کی خرابیوں کے حل کی رہنما میں۔ اسے کینونیکل نام اور CMS ترتیب کے مطابق ہونے کے بعد چلائیں، پہلے نہیں، ورنہ آپ وہی قدر کیش کریں گے جو آپ بدلنے والے ہیں۔

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

مرحلہ 3: CiviCRM کے بنائے گئے پتے جانچیں

سرورق تک پہنچنا بہت کم ثابت کرتا ہے۔ CiviCRM ایک CMS کے اندر چلتا ہے، اور اہم صفحات وہ ہیں جو اپنے URL خود بناتے ہیں: لاگ ان ری ڈائریکٹ، انتظامی مینو، ایکسٹینشن وسائل، اپلوڈ شدہ فائلوں کے لنک اور کوئی بھی بیرونی کال بیک جو کسی انٹیگریشن نے رجسٹر کیا ہو۔

ڈیش بورڈ لوڈ کریں، رابطہ ریکارڈ کھولیں، اور مطلق لنکس کے لیے صفحے کا سورس دیکھیں۔ اگر وہ ایسے ہوسٹ نام کی طرف اشارہ کریں جہاں صرف ایک کلائنٹ گروپ پہنچ سکتا ہے، تو صفحہ دکھنے کے باوجود بنیادی URL اب بھی غلط ہے۔ اگر وہ درست نام مگر غلط اسکیم کی طرف اشارہ کریں، تو پراکسی کنفیگریشن ٹھیک کرنے والی چیز ہے۔

جہاں پتہ واقعی بدلنا ضروری ہو، اسے DNS ترمیم نہیں بلکہ ایپلیکیشن منتقلی سمجھیں۔ وسائل کے URL، کیش، شائع شدہ لنک اور پرانا پتہ محفوظ رکھنے والی ہر بیرونی انٹیگریشن کا جائزہ لیں، پھر انہیں ایک ہی ونڈو میں اپ ڈیٹ کریں تاکہ کسی کے پاس آدھی منتقل شدہ بک مارک نہ رہے۔

درخواست کا ہوسٹ نام اعتماد کا فیصلہ نہیں ہے

کسی درخواست ہیڈر میں مخصوص سٹرنگ ہونے کی وجہ سے مراعات یافتہ بنیادی URL نہ چنیں۔ PHP ایسی Apache کنفیگریشنز کی دستاویز کرتا ہے جن میں سرور نام کی قدر کلائنٹ کی فراہم کردہ ہوسٹ کی عکاسی کر سکتی ہے، اور سرور پتہ متغیر سرور کو بیان کرتا ہے، دیکھنے والے کے مقام کو نہیں۔ ان میں سے کوئی رسائی کنٹرول کا طریقہ کار نہیں ہے، اور ان میں سے ایک بنانا ہی وہ راستہ ہے جس سے نجی خدمت غلط ہوسٹ کو غلط مواد دینے لگتی ہے۔

اگر واقعی متعدد ہوسٹ نام درکار ہوں، ویب سرور، CMS اور ایپلیکیشن پرت میں واضح اجازت فہرست ترتیب دیں، اور درخواست کے ہوسٹ نام کو صرف منظور شدہ اندراجات میں سے چننے دیں۔ من مانی ان پٹ کو کبھی مطلق لنکس یا قابل اعتماد ری ڈائریکٹ منزل کا ذریعہ نہیں بننا چاہیے۔

ہر منظور شدہ سیاق میں اسی بک مارک کے ساتھ ختم کریں: لاگ ان، عام اندرونی نیویگیشن اور ایک وسیلہ درخواست۔ جوابات میں ہوسٹ ناموں کا موازنہ کریں، صرف یہ نہیں کہ صفحہ لوڈ ہوا یا نہیں۔ وہ تین درخواستوں کی جانچ راستے کے مسئلے کو اس ایپلیکیشن سے الگ کرتی ہے جو اب بھی غلط پتہ بنا رہی ہے، اور ہر کلائنٹ گروپ کے لیے تقریباً ایک منٹ لیتی ہے۔