ਸਾਂਝੇ ਸਬਡੋਮੇਨ, ਦੋ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ: ਕੌਣ ਕਿਹੜੇ ਰਿਕਾਰਡ ਦੇਖਦਾ ਹੈ?

ਕਲਿਨਿਕ 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

ਫਿਰ ਇਜਾਜ਼ਤ-ਸੂਚੀ ਦੀ ਇੱਕ ਐਂਟਰੀ ਬਦਲੋ ਅਤੇ ਦੁਬਾਰਾ ਚਲਾਓ। ਹਿਲਣ ਵਾਲਾ ਨਤੀਜਾ ਭਾਵ ਨੈੱਟਵਰਕ ਨਿਯੰਤਰਣ ਅਧਿਕਾਰ ਦਾ ਫ਼ੈਸਲਾ ਲੈ ਰਿਹਾ ਹੈ।

ਫਰੰਟਐਂਡ ਵਿੱਚ ਕਿਸੇ ਵੀ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਮੈਟ੍ਰਿਕਸ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਜਾਂਚ ਛੱਡਣ ਵਾਲਾ ਦੂਜਾ ਕੋਡ-ਮਾਰਗ ਇਸ ਸੀਮਾ ਦੇ ਖੋਰ ਦਾ ਸਭ ਤੋਂ ਆਮ ਤਰੀਕਾ ਹੈ। ਉਮੀਦ ਕੀਤਾ ਨਤੀਜਾ ਬੇਸੁਆਦ ਹੈ: ਹਰ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ ਉਹੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।