ಕಚೇರಿ ಮತ್ತು VPN ಬಳಕೆದಾರರಿಗೆ ಒಂದೇ CiviCRM URL: ಸೆಟಪ್ ಹಂತಗಳು

ಕಚೇರಿಯ ಲ್ಯಾಪ್ಟಾಪ್ ತನ್ನ ಮೇಜಿನಲ್ಲಿ ಮತ್ತು ಮನೆಯಿಂದ VPN ಮೂಲಕ ಮತ್ತೆ ಅದೇ CiviCRM ಬುಕ್ಮಾರ್ಕ್ ತೆರೆಯಬೇಕು. ಬಳಕೆದಾರರ ಸಂಪರ್ಕದಲ್ಲಿ ಉಳಿಯುವ ವಿನ್ಯಾಸವೆಂದರೆ ಒಂದು ನಿಯಮಬದ್ಧ ವಿಳಾಸ, ಹೇಳಿಕೆ https://crm.example.org/, ಪ್ರತಿ ಸ್ಥಳದಿಂದ ಅನುಮೋದಿತ ನೆಟ್ವರ್ಕ್ ಮಾರ್ಗ ಮತ್ತು ಆ ಹೆಸರಿಗೆ ಮಾನ್ಯವಾದ ಪ್ರಮಾಣಪತ್ರದೊಂದಿಗೆ. VPN ರಿಮೋಟ್ ಕ್ಲೈಂಟ್ ಸರ್ವರ್ಗೆ ಹೇಗೆ ತಲುಪುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಅದು ಎಂದಿಗೂ ಅಪ್ಲಿಕೇಶನ್ನ ಗುರುತನ್ನು ಬದಲಾಯಿಸಬಾರದು, ಏಕೆಂದರೆ ಅದು ಹಾಗೆ ಮಾಡುವ ಕ್ಷಣದಲ್ಲಿ ಪ್ರತಿ ರಚಿತ ಕೊಂಡಿ, ಮರುನಿರ್ದೇಶನ ಮತ್ತು ಏಕೀಕರಣ ಕಾಲ್ಬ್ಯಾಕ್ ಪರಿಹರಿಸಬೇಕಾದ ಎರಡನೇ ಸಮಸ್ಯೆಯಾಗುತ್ತದೆ.

ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು URL ಆಯ್ಕೆ ಮಾಡಿ

ಮೊದಲು ಉದ್ದೇಶಿತ ವಿಳಾಸವನ್ನು ಬರೆಯಿರಿ, CMS ಗೆ ಬೇಕಾದ ಯಾವುದೇ ಪಥ ಘಟಕ ಸೇರಿಸಿ, ಮತ್ತು ಅದನ್ನು ಸ್ಥಿರ ಬಿಂದುವಾಗಿ ಪರಿಗಣಿಸಿ. ಈ ಕೈಪಿಡಿಯಲ್ಲಿ ಉಳಿದದ್ದೆಲ್ಲವೂ ಅದನ್ನು ಮುಟ್ಟದೆ ಬದಲಾಗಬಹುದಾದ ಅನುಷ್ಠಾನ ವಿವರ: ಪ್ರತಿ ಗುಂಪಿಗೆ ಯಾವ DNS ಉತ್ತರ ಸಿಗುತ್ತದೆ, ಯಾವ ಫೈರ್ವಾಲ್ ನಿಯಮ ಆಲಿಸುವವರಿಗೆ ಅನುಮತಿ ನೀಡುತ್ತದೆ, ಮತ್ತು ಸಂಚಾರವು ಸುರಂಗದ ಮೂಲಕ ಬರುತ್ತದೆಯೇ ಅಥವಾ ಸ್ಥಳೀಯ ಸ್ವಿಚ್ ಪೋರ್ಟ್ ಮೂಲಕ.

ಪ್ರವೇಶ ಯೋಜನೆಯಲ್ಲಿ ನಾಲ್ಕು ಮೌಲ್ಯಗಳನ್ನು ಒಟ್ಟಿಗೆ ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಅವು ಒಂದು ಗುಂಪಾಗಿಯೇ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ನಿಯಮಬದ್ಧ 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 ಜೋಡಿಸಿ

ಆಲಿಸುವವರು ನಿಯಮಬದ್ಧ ಹೆಸರಿಗೆ ಸೇವೆ ನೀಡಲು ಸಂರಚಿಸಲ್ಪಡಬೇಕು, ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಅದನ್ನು ಆವರಿಸಬೇಕು. ಕಚ್ಚಾ ವಿಳಾಸದಿಂದ ಬ್ರೌಸ್ ಮಾಡುವುದು ಪರಿಹಾರವಲ್ಲ: ಅದು ಹೆಸರಿನ ಹೊಂದಾಣಿಕೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಕುಕಿ ವ್ಯಾಪ್ತಿಯನ್ನು ಮುರಿಯಬಹುದು, ಮತ್ತು ನೀವು ನಂತರ ಆಡಿಟರ್ಗೆ ವಿವರಿಸಬೇಕಾದ ಎಚ್ಚರಿಕೆಗಳ ಮೂಲಕ ಕ್ಲಿಕ್ ಮಾಡಲು ಬಳಕೆದಾರರಿಗೆ ಕಲಿಸುತ್ತದೆ.

ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಹಿಂದೆ, ವಿನಂತಿ 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 ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಪದರದಲ್ಲಿ ಸ್ಪಷ್ಟ ಅನುಮತಿ ಪಟ್ಟಿಯನ್ನು ಸಂರಚಿಸಿ, ಮತ್ತು ವಿನಂತಿಯ ಹೋಸ್ಟ್ನಾಮವು ಅನುಮೋದಿತ ನಮೂದುಗಳಿಂದ ಮಾತ್ರ ಆಯ್ಕೆ ಮಾಡಲಿ. ಅನಿಯಂತ್ರಿತ ಇನ್ಪುಟ್ ಎಂದಿಗೂ ಸಂಪೂರ್ಣ ಕೊಂಡಿಗಳ ಮೂಲ ಅಥವಾ ವಿಶ್ವಾಸಾರ್ಹ ಮರುನಿರ್ದೇಶನ ಗಮ್ಯಸ್ಥಾನವಾಗಬಾರದು.

ಪ್ರತಿ ಅನುಮೋದಿತ ಸಂದರ್ಭದಲ್ಲಿ ಅದೇ ಬುಕ್ಮಾರ್ಕ್ನೊಂದಿಗೆ ಮುಗಿಸಿ: ಒಂದು ಲಾಗಿನ್, ಸಾಮಾನ್ಯ ಆಂತರಿಕ ನ್ಯಾವಿಗೇಷನ್ ಮತ್ತು ಒಂದು ಸಂಪನ್ಮೂಲ ವಿನಂತಿ. ಪ್ರತಿಕ್ರಿಯೆಗಳಲ್ಲಿನ ಹೋಸ್ಟ್ನಾಮಗಳನ್ನು ಹೋಲಿಸಿ, ಪುಟ ಲೋಡ್ ಆಯಿತೇ ಎಂಬುದನ್ನು ಮಾತ್ರವಲ್ಲ. ಈ ಮೂರು-ವಿನಂತಿ ಪರಿಶೀಲನೆ ಮಾರ್ಗದ ಸಮಸ್ಯೆಯನ್ನು ಇನ್ನೂ ತಪ್ಪು ವಿಳಾಸ ರಚಿಸುತ್ತಿರುವ ಅಪ್ಲಿಕೇಶನ್ನಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಗುಂಪಿಗೆ ಸುಮಾರು ಒಂದು ನಿಮಿಷ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.