ઓફિસ અને 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 રાખે છે અને તેને ફરી ગણતરી કરવાની સમર્થિત રીત આપે છે: વહીવટી 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 અને એપ્લિકેશન સ્તરે સ્પષ્ટ મંજૂર-યાદી ગોઠવો, અને વિનંતીના હોસ્ટનામને ફક્ત મંજૂર કરેલી એન્ટ્રીઓમાંથી પસંદ કરવા દો. મનસ્વી ઇનપુટ ક્યારેય સંપૂર્ણ લિંક્સનો સ્રોત કે વિશ્વસનીય રીડાયરેક્ટ ગંતવ્ય બનવું ન જોઈએ.

દરેક મંજૂર સંદર્ભમાં એ જ બુકમાર્ક સાથે સમાપ્ત કરો: એક લોગિન, એક સામાન્ય આંતરિક નેવિગેશન અને એક સ્રોત વિનંતી. જવાબોમાં હોસ્ટનામની સરખામણી કરો, ફક્ત પૃષ્ઠ લોડ થયું કે નહીં તે નહીં. ત્રણ-વિનંતીની આ ચકાસણી માર્ગની સમસ્યાને એવી એપ્લિકેશનથી અલગ પાડે છે જે હજી ખોટું સરનામું જનરેટ કરી રહી છે, અને તે દરેક ક્લાયન્ટ જૂથ દીઠ લગભગ એક મિનિટ લે છે.