ಹಂಚಿಕೊಂಡ ಸಬ್‌ಡೊಮೇನ್‌ಗಳು, ಎರಡು ಪ್ರವೇಶದ್ವಾರಗಳು: ಯಾರು ಯಾವ ದಾಖಲೆಗಳನ್ನು ನೋಡುತ್ತಾರೆ?

ಕ್ಲಿನಿಕ್ A ಮತ್ತು ಕ್ಲಿನಿಕ್ B ಒಂದು ಕೋಡ್‌ಬೇಸ್, ಎರಡು ಸಬ್‌ಡೊಮೇನ್‌ಗಳು ಮತ್ತು ಕಚೇರಿಯಿಂದ ಹಾಗೂ VPN ಮೂಲಕ ಬರುವ ಸಂದರ್ಶಕರ ಮಿಶ್ರಣವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ. ನೆಟ್‌ವರ್ಕ್ ತಂಡಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ಪ್ರವೇಶದ್ವಾರಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂರಚಿಸುತ್ತವೆ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಹಾಗೆ ಮಾಡದಿರುವವರೆಗೆ ಅದು ಸರಿಯೇ. ಕೆಳಗಿನ ಪರಿಶೀಲನೆಗಳು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲೇ ಇರಬೇಕು ಮತ್ತು ವಿನಂತಿ ಯಾವ ಬಾಗಿಲನ್ನು ಬಳಸಿತು ಎಂಬುದನ್ನು ಲೆಕ್ಕಿಸದೆ ಒಂದೇ ರೀತಿ ವರ್ತಿಸಬೇಕು.

ಮೊದಲನೆಯದು: ಹೋಸ್ಟ್‌ಹೆಸರು ಒಂದು ಟೆನೆಂಟ್‌ಗೆ ಮಾತ್ರ ಹೆಸರು ಕೊಡುತ್ತದೆ

ಕೋರಿದ ಹೋಸ್ಟ್‌ಹೆಸರನ್ನು ನಿರ್ವಾಹಕರು ನಿರ್ವಹಿಸುವ ಮ್ಯಾಪಿಂಗ್ ವಿರುದ್ಧ ಪರಿಹರಿಸಿ ಮತ್ತು ಅಪರಿಚಿತವಾದುದನ್ನು ತಿರಸ್ಕರಿಸಿ. ಕಚ್ಚಾ ಹೆಡರ್‌ನ ಬದಲು ಫ್ರೇಮ್‌ವರ್ಕ್‌ನ ಮಾನ್ಯಗೊಳಿಸಿದ ಹೋಸ್ಟ್ ಮೌಲ್ಯವನ್ನು ಬಳಸಿ, ಇದರಿಂದ ಸೃಷ್ಟಿಸಿದ Host ಲುಕ್‌ಅಪ್ ಕೀಯನ್ನು ಚುಚ್ಚಲು ಸಾಧ್ಯವಾಗದು. ಯಶಸ್ವಿ ಹೊಂದಾಣಿಕೆ ಯಾವ ಟೆನೆಂಟ್ ಸಂರಚನೆ ಮತ್ತು ಯಾವ ಬ್ರಾಂಡಿಂಗ್ ಲೋಡ್ ಮಾಡಬೇಕೆಂದು ಕೋಡ್‌ಗೆ ಹೇಳುತ್ತದೆ. ಆದರೆ ಕರೆ ಮಾಡುವವರು ಆ ಟೆನೆಂಟ್‌ನ ಡೇಟಾವನ್ನು ನೋಡಬಹುದೇ ಎಂಬುದನ್ನು ಅದು ಹೇಳುವುದಿಲ್ಲ. ಆ ಎರಡನೆಯ ಪ್ರಶ್ನೆಯನ್ನು ಪ್ರತ್ಯೇಕ ಇನ್‌ಪುಟ್‌ನೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ ಫಂಕ್ಷನ್‌ನಲ್ಲಿ ಇರಿಸಿ.

ಒಂದೇ ಹೋಸ್ಟ್‌ಹೆಸರು ಹುಡುಕಾಟದಿಂದ ಸಂದರ್ಭ ಮತ್ತು ಅನುಮತಿ ಎರಡನ್ನೂ ಹಿಂತಿರುಗಿಸುವ ಹಂಚಿಕೊಂಡ ಸಹಾಯಕ ಫಂಕ್ಷನ್ ಬಗ್‌ನ ಆರಂಭ.

ಎರಡನೆಯದು: ಸದಸ್ಯತ್ವ ಸೆಷನ್‌ನಿಂದ ಬರುತ್ತದೆ

ದೃಢೀಕೃತ ಬಳಕೆದಾರರ ಸಕ್ರಿಯ ಸದಸ್ಯತ್ವಗಳನ್ನು ಹುಡುಕಿ ಮತ್ತು ಅವನ್ನು ಮೊದಲ ಪರಿಶೀಲನೆಯ ಟೆನೆಂಟ್‌ನೊಂದಿಗೆ ಹೋಲಿಸಿ. ಎರಡೂ ಕ್ಲಿನಿಕ್‌ಗಳಿಗೆ ಸೇರಿದ ಬಳಕೆದಾರರು ಬದಲಾಯಿಸಬಹುದು, ಆದರೆ ಆ ಬದಲಾವಣೆ ವಿನಂತಿಯ ಸಂದರ್ಭದಲ್ಲಿ ದಾಖಲಾದ ಸ್ಪಷ್ಟ ಕ್ರಿಯೆಯಾಗಿರಬೇಕು, URL ನಿಂದ ಮಾಡಿದ ಊಹೆಯಲ್ಲ. ಒಂದು ಕ್ಲಿನಿಕ್‌ಗೆ ಸೇರಿದ ಬಳಕೆದಾರರು ಇನ್ನೊಂದನ್ನು ಕೋರಿದರೆ ನಿರಾಕರಿಸಲಾಗುತ್ತದೆ, ಡೌನ್‌ಲೋಡ್‌ಗಳು ಮತ್ತು API ಕರೆಗಳೂ ಸೇರಿದಂತೆ.

ದಾಖಲೆ ಗುರುತಿಸುವಿಕೆ ಮತ್ತು ಟೆನೆಂಟ್ ಪ್ಯಾರಾಮೀಟರ್ ಸಂಪಾದಿಸಿ ಋಣಾತ್ಮಕ ಪ್ರಕರಣವನ್ನು ಪರೀಕ್ಷಿಸಿ. ಎರಡರಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆ ಡೇಟಾವನ್ನು ಹಿಂತಿರುಗಿಸಿದರೆ, ವ್ಯಾಪ್ತಿಯನ್ನು ಪರಿಶೀಲಿಸಿದ ಸದಸ್ಯತ್ವದಿಂದ ಅಲ್ಲ, ವಿನಂತಿಯಿಂದ ಓದಲಾಗುತ್ತಿದೆ.

ಕುಕಿ ವ್ಯಾಪ್ತಿ ಮತ್ತು ಏಕ ಸೈನ್-ಆನ್ ಖಾತೆಯನ್ನು ಎಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಬಹುದೆಂದು ನಿರ್ಧರಿಸುತ್ತವೆ. ಆ ಖಾತೆ ಏನನ್ನು ಓದಬಹುದೆಂದು ಅವು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ.

ಮೂರನೆಯದು: ನೆಟ್‌ವರ್ಕ್ ವ್ಯಕ್ತಿಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ

VPN ಗೇಟ್‌ವೇ ಸುರಂಗವನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಸಾರ್ವಜನಿಕ ಅನುಮತಿ ಪಟ್ಟಿ ವಿಳಾಸ ಶ್ರೇಣಿಯನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ. ಎರಡೂ ವ್ಯಕ್ತಿಯನ್ನು ಗುರುತಿಸುವುದಿಲ್ಲ. NAT ಅನೇಕ ಬಳಕೆದಾರರನ್ನು ಒಂದೇ ಮೂಲ ವಿಳಾಸಕ್ಕೆ ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ಕಚೇರಿ ಶ್ರೇಣಿ ಕಟ್ಟಡದಲ್ಲಿರುವ ಎಲ್ಲರಿಗೂ ಅದನ್ನೇ ಮಾಡುತ್ತದೆ. ಎರಡನ್ನೂ ಸಾಗಣೆ ಸತ್ಯಗಳಾಗಿ ಪರಿಗಣಿಸಿ ಮತ್ತು ಅಧಿಕಾರವನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲೇ ಇರಿಸಿ, ಅಥವಾ ಗುರುತನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪ್ರತಿಪಾದಿಸುವ ಮತ್ತು ಅದೇ ರೀತಿ ಪರಿಶೀಲಿಸಲ್ಪಡುವ ಏಕೀಕರಣದಲ್ಲಿಡಿ.

DNS ಮೂರನೆಯ ಸಾಗಣೆ ಸತ್ಯ. ಖಾಸಗಿ ಉತ್ತರಕ್ಕೆ ಖಾಸಗಿ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ಸಾರ್ವಜನಿಕ ಫ್ರಂಟ್‌ಎಂಡ್‌ಗೆ ಬೆಂಬಲಿತ ಮೂಲ ಮಾರ್ಗ ಬೇಕು. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಅನುಮತಿಯನ್ನು ಹೊತ್ತೊಯ್ಯುವುದಿಲ್ಲ.

ಗೋಡೆಗೆ ಅಂಟಿಸಲು ಒಂದು ವಾಕ್ಯ: ನೆಟ್‌ವರ್ಕ್ ವಿನಂತಿ ಹೇಗೆ ಬರುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅದು ಏನನ್ನು ಓದಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

ನಾಲ್ಕನೆಯದು: ಎರಡೂ ಪ್ರವೇಶದ್ವಾರಗಳಲ್ಲಿ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಚಲಾಯಿಸಿ

ನಿಯಂತ್ರಿತ ಖಾತೆಗಳನ್ನು ಬಳಸಿ A ಅನ್ನು A ನಲ್ಲಿ, B ಅನ್ನು B ನಲ್ಲಿ, A ಅನ್ನು B ನಲ್ಲಿ, ಅಪರಿಚಿತ ಹೋಸ್ಟ್‌ಹೆಸರನ್ನು ಮತ್ತು ಸದಸ್ಯತ್ವವಿಲ್ಲದ ದೃಢೀಕೃತ ಖಾತೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ. ನಾಲ್ಕನೆಯದು ಮತ್ತು ಐದನೆಯದು ಮುಚ್ಚಿದ ರೀತಿಯಲ್ಲಿ ವಿಫಲಗೊಳ್ಳಬೇಕು ಮತ್ತು ಎಂದಿಗೂ ಡೀಫಾಲ್ಟ್ ಟೆನೆಂಟ್‌ಗೆ ಬೀಳಬಾರದು. ಅದೇ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಅನ್ನು VPN ಪ್ರವೇಶದ್ವಾರದ ಮೂಲಕವೂ ಚಲಾಯಿಸಿ, ಪ್ರತಿ ಖಾತೆಗೆ ಒಂದು ಸೆಷನ್ ಜಾರ್‌ನೊಂದಿಗೆ:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

ನಂತರ ಅನುಮತಿ ಪಟ್ಟಿಯಲ್ಲಿ ಒಂದು ನಮೂದನ್ನು ಬದಲಿಸಿ ಮತ್ತೆ ಚಲಾಯಿಸಿ. ಚಲಿಸುವ ಫಲಿತಾಂಶ ಎಂದರೆ ನೆಟ್‌ವರ್ಕ್ ನಿಯಂತ್ರಣವೊಂದು ಅಧಿಕಾರದ ನಿರ್ಣಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದೆ.

ಫ್ರಂಟ್‌ಎಂಡ್‌ನ ಯಾವುದೇ ಬದಲಾವಣೆಯ ನಂತರ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ಪರಿಶೀಲನೆಯನ್ನು ಬಿಟ್ಟುಬಿಡುವ ಎರಡನೆಯ ಕೋಡ್ ಮಾರ್ಗವೇ ಈ ಗಡಿ ಸವೆತದ ಸಾಮಾನ್ಯ ದಾರಿ. ನಿರೀಕ್ಷಿತ ಫಲಿತಾಂಶ ನೀರಸವಾಗಿದೆ: ಪ್ರತಿ ಪ್ರವೇಶದ್ವಾರವೂ ಅದೇ ಉತ್ತರಗಳನ್ನು ನೀಡುತ್ತದೆ.