د دفتر او 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 او اپلیکیشن طبقې کې واضح اجازه لیست تنظیم کړئ، او اجازه ورکړئ چې د غوښتنې هوسټ نوم یوازې د تصویب شوو ننوتلو څخه وټاکي۔ خپل سري انپټ باید هیڅکله د مطلق لینکونو یا باوري بیا لارښوونې منزل سرچینه نه شي۔

په هر تصویب شوي زمینه کې د ورته بک مارک سره پای ته ورسئ: یو ننوتل، یو عادي داخلي تګ راتګ، او یوه سرچینه غوښتنه۔ په ځوابونو کې هوسټ نومونه پرتله کړئ، نه یوازې دا چې پاڼه بار شوه که نه۔ هغه درې غوښتنې ازموینه د لارې ستونزه له هغه اپلیکیشن څخه جلا کوي چې لا هم غلطه پته جوړوي، او د هر کلینټ ګروپ لپاره شاوخوا یوه دقیقه وخت نیسي۔