ერთი CiviCRM მისამართი ოფისისა და VPN მომხმარებლებისთვის: კონფიგურაციის ნაბიჯები

ოფისის ლეპტოპმა ერთი და იგივე CiviCRM სანიშნე უნდა გახსნას მაგიდასთან და შემდეგ სახლიდან VPN-ის მეშვეობით. დიზაინი, რომელიც მომხმარებლებთან შეხებას უძლებს, ერთი კანონიკური მისამართია, ვთქვათ https://crm.example.org/, დამტკიცებული ქსელური გზით თითოეული ადგილიდან და სერტიფიკატით, რომელიც ამ სახელისთვის ძალაშია. VPN ცვლის, როგორ აღწევს დისტანციური კლიენტი სერვერამდე. მან არასოდეს უნდა შეცვალოს აპლიკაციის იდენტობა, რადგან იმ მომენტში, როცა ამას აკეთებს, ყოველი გენერირებული ბმული, გადამისამართება და ინტეგრაციის უკუგამოძახება მოსაგვარებელ მეორე პრობლემად იქცევა.

აირჩიეთ URL სანამ გზას აირჩევთ

ჯერ ჩაწერეთ განზრახული მისამართი, CMS-ისთვის საჭირო ნებისმიერი ბილიკის კომპონენტის ჩათვლით, და მოეპყარით მას როგორც ფიქსირებულ წერტილს. დანარჩენი ყველაფერი ამ სახელმძღვანელოში იმპლემენტაციის დეტალია, რომელიც შეიძლება შეიცვალოს მასზე ხელის შეუხებლად: რომელი DNS პასუხი მიიღოს თითოეულმა ჯგუფმა, რომელი firewall წესი უშვებს მსმენელს და მოდის თუ არა ტრაფიკი გვირაბით ან ლოკალური კომუტატორის პორტით.

ჩაწერეთ ოთხი მნიშვნელობა ერთად წვდომის გეგმაში, რადგან ისინი მხოლოდ როგორც ერთობლიობა მუშაობს. კანონიკური URL. პასუხი, რომელიც თითოეულმა კლიენტთა ჯგუფმა უნდა მიიღოს ამ სახელისთვის. გზა და წვდომის წესი ამ პასუხისთვის. ჰოსტის სახელი, რომლის მომსახურებაზეც ვებ სერვერი და სერტიფიკატია კონფიგურირებული. როცა მოგვიანებით რაღაც გატყდება, გატეხილი ელემენტი ამ ოთხიდან ერთ-ერთია და გაიგებთ, რომელი შეცვალეთ.

ნაბიჯი 1: დარწმუნდით, რომ სახელი ორივე ჯგუფისთვის სწორად წყდება

ორივე ჯგუფმა უნდა მიიღოს პირადი პასუხი, რომელზეც ნამდვილად შეუძლია მიღწევა, და ლეგიტიმურია პასუხები განსხვავდებოდეს, სანამ სახელი არ განსხვავდება. LAN კლიენტები შიდა გამხსნელით წყვეტენ; VPN კლიენტებს სჭირდებათ გამხსნელის პოლიტიკა, რომელიც მათ იმავე ზონას აძლევს, ნაცვლად იმისა, რომ მოთხოვნა საჯარო გამხსნელში გაჟონოს და მიიღონ საჯარო პასუხი, რომელსაც ვერ გამოიყენებენ.

შეამოწმეთ სახელი თითოეული კონტექსტიდან დაშვების ნაცვლად, და შეამოწმეთ გზა DNS-ისგან დამოუკიდებლად curl-ის resolve ოფციით, რომელიც მისამართს ერთი მოთხოვნისთვის ამაგრებს:

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

მსმენელი კონფიგურირებული უნდა იყოს კანონიკური სახელის მოსამსახურებლად, და სერტიფიკატმა ის უნდა დაფაროს. ნედლი მისამართით დათვალიერება გამოსავალი არ არის: ის ქმნის სახელის შეუსაბამობას, შეიძლება დაარღვიოს cookie-ების არეალი და ასწავლის მომხმარებლებს, გადალახონ გაფრთხილებები, რომლებიც მოგვიანებით აუდიტორისთვის უნდა ახსნათ.

საპირისპირო პროქსის უკან დარწმუნდით, რომ აპლიკაციამ იცის: მოთხოვნა HTTPS-ით მოვიდა. CMS პლატფორმების უმეტესობა აბსოლუტურ ბმულებს აღმოჩენილი სქემიდან აგენერირებს, და პროქსი, რომელიც TLS-ს თავდაპირველი სქემის გადაცემის გარეშე ასრულებს, ქმნის გვერდს, სავსეს http:// რესურსებით, რომლებიც ბრაუზერმა შეიძლება დაბლოკოს. კონფიგურირეთ სანდო პროქსი და გადაცემული სათაურები ცხადად, ნაცვლად იმისა, რომ აპლიკაციას გამოცნობა დაუტოვოთ.

შემდეგ შეათანხმეთ CMS-ისა და CiviCRM-ის საბაზო URL. CiviCRM ინარჩუნებს თავის განსაზღვრულ საბაზო URL-ს და გვთავაზობს მხარდაჭერილ გზას მისი ხელახლა გამოთვლისთვის: ადმინისტრაციული მოქმედება Cleanup Caches and Update Paths, რომელიც დოკუმენტირებულია 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-ში და აპლიკაციის დონეზე, და მიეცით მოთხოვნის ჰოსტის სახელს მხოლოდ დამტკიცებული ჩანაწერებიდან არჩევის საშუალება. თვითნებური შეყვანა არასოდეს უნდა გახდეს აბსოლუტური ბმულების წყარო ან სანდო გადამისამართების დანიშნულება.

დაასრულეთ იმავე სანიშნეთი თითოეულ დამტკიცებულ კონტექსტში: შესვლა, ჩვეულებრივი შიდა ნავიგაცია და ერთი რესურსის მოთხოვნა. შეადარეთ ჰოსტის სახელები პასუხებში და არა მხოლოდ ის, გაიხსნა თუ არა გვერდი. სამმოთხოვნიანი ეს შემოწმება გამოყოფს გზის პრობლემას იმ აპლიკაციისგან, რომელიც კვლავ არასწორ მისამართს აგენერირებს, და თითოეულ კლიენტთა ჯგუფზე დაახლოებით ერთ წუთს იკავებს.