కార్యాలయం మరియు VPN వినియోగదారుల కోసం ఒక CiviCRM URL: సెటప్ దశలు

ఆఫీసు ల్యాప్టాప్ తన డెస్క్ వద్ద అదే CiviCRM బుక్మార్క్ను మరియు ఇంటి నుండి VPN ద్వారా మళ్లీ తెరవాలి. వినియోగదారులతో సంబంధాన్ని తట్టుకునే డిజైన్ ఒక కానానికల్ చిరునామా, చెప్పాలంటే 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ని ఎంచుకోకండి. సర్వర్-పేరు విలువ క్లయింట్ అందించిన హోస్ట్ను ప్రతిబింబించగల Apache కాన్ఫిగరేషన్లను PHP డాక్యుమెంట్ చేస్తుంది, మరియు సర్వర్ చిరునామా వేరియబుల్ సర్వర్ను వివరిస్తుంది, సందర్శకుడి స్థానాన్ని కాదు. వాటిలో ఏదీ యాక్సెస్ నియంత్రణ యంత్రాంగం కాదు, మరియు వాటిలో ఒకటి నిర్మించడం అనేది ప్రైవేట్ సేవ తప్పు హోస్ట్కు తప్పు కంటెంట్ను అందించడం ప్రారంభించే మార్గం.

నిజంగా బహుళ హోస్ట్నామ్లు అవసరమైతే, వెబ్ సర్వర్, CMS మరియు అప్లికేషన్ పొరలో స్పష్టమైన అనుమతి జాబితాను కాన్ఫిగర్ చేయండి, మరియు అభ్యర్థన హోస్ట్నామ్ ఆమోదించిన ఎంట్రీల మధ్య మాత్రమే ఎంచుకోనివ్వండి. ఏకపక్ష ఇన్పుట్ ఎప్పుడూ సంపూర్ణ లింకులకు లేదా విశ్వసనీయ మళ్లింపు గమ్యానికి మూలం కాకూడదు.

ఆమోదించిన ప్రతి సందర్భంలో అదే బుక్మార్క్తో ముగించండి: ఒక లాగిన్, సాధారణ అంతర్గత నావిగేషన్ మరియు ఒక వనరు అభ్యర్థన. పేజీ లోడ్ అయిందా అని మాత్రమే కాదు, ప్రతిస్పందనల్లోని హోస్ట్నామ్లను పోల్చండి. ఆ మూడు-అభ్యర్థన పరీక్ష మార్గ సమస్యను ఇంకా తప్పు చిరునామాను సృష్టిస్తున్న అప్లికేషన్ నుండి వేరు చేస్తుంది, మరియు ప్రతి క్లయింట్ గ్రూప్కు సుమారు ఒక నిమిషం పడుతుంది.