ਸਟੇਜਿੰਗ ਉਤਪਾਦਨ ਨਹੀਂ ਹੈ: ਇਸ ਨੂੰ ਆਪਣੀ ਖੁਦ ਦੀ ਪਹੁੰਚ ਸੀਮਾ ਦਿਓ
ਸਟੇਜਿੰਗ ਲੇਬਲ ਇਹ ਤੈਅ ਨਹੀਂ ਕਰਦਾ ਕਿ ਐਪ ਤੱਕ ਕੌਣ ਪਹੁੰਚਦਾ ਹੈ ਜਾਂ ਇਹ ਕਿਸ ਨੂੰ ਛੂਹ ਸਕਦਾ ਹੈ। ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦਰਸ਼ਕ, ਡੇਟਾ, ਪ੍ਰਮਾਣ-ਪੱਤਰ ਅਤੇ ਐਡਮਿਨ ਸਤਹਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ।
ਸਟੇਜਿੰਗ ਇੱਕ ਟੈਸਟ ਸਿਸਟਮ ਵਾਂਗ ਦਿਸਦਾ ਹੈ, ਜਦ ਤੱਕ ਤੁਸੀਂ ਇਸ ਦੇ ਵਾਤਾਵਰਨ ਵਿੱਚ ਨਕਲ ਕੀਤਾ ਉਤਪਾਦਨ ਡੇਟਾਬੇਸ, ਜੀਵਤ ਮੇਲ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਅਤੇ ਭੁਗਤਾਨ ਕੁੰਜੀ ਨਹੀਂ ਵੇਖਦੇ। ਉਸ ਪਲ ਟੈਬ ਉੱਤੇ ਲੱਗਾ ਲੇਬਲ ਮਹੱਤਵ ਗੁਆ ਦਿੰਦਾ ਹੈ ਅਤੇ ਅਸਲ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਇਹ ਤੈਨਾਤੀ ਕਿੱਥੋਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ ਅਤੇ ਉੱਥੇ ਤੱਕ ਕੌਣ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਅੱਗੇ ਦੇ ਦਰਵਾਜ਼ੇ ਦਾ VPN ਉਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ, ਕਿਉਂਕਿ ਇਹ ਸਿਸਟਮ ਵਿੱਚ ਜਾਣ ਦਾ ਇੱਕ ਹੀ ਰਾਹ ਸੀਮਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਸਿਸਟਮ ਬਾਹਰ ਜਾਂਦਿਆਂ ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਦਰਸ਼ਕਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਬਾਹਰ ਵੱਲ ਵਧੋ।
URL ਤੋਂ ਨਹੀਂ, ਦਰਸ਼ਕਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ
ਤਿੰਨ ਦਰਸ਼ਕ ਤਿੰਨ ਵੱਖਰੇ ਡਿਜ਼ਾਈਨ ਦਿੰਦੇ ਹਨ। ਨਿੱਜੀ ਇੰਜੀਨੀਅਰਿੰਗ ਵਾਤਾਵਰਨ ਨੂੰ ਪਛਾਣ ਅਤੇ ਮਾਰਗ ਚਾਹੀਦਾ ਹੈ; ਗਾਹਕ ਸਵੀਕ੍ਰਿਤੀ ਟੈਸਟ ਨੂੰ ਗਾਹਕਾਂ ਦੀ ਨੁਮਾਇੰਦਗੀ ਕਰਨ ਵਾਲੇ ਖਾਤੇ ਚਾਹੀਦੇ ਹਨ; ਜਨਤਕ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਆਪਣੇ ਨਿਯੰਤਰਣਾਂ ਨਾਲ ਜਾਣ-ਬੁੱਝ ਕੇ ਕੀਤਾ ਪਰਦਰਸ਼ਨ ਚਾਹੀਦਾ ਹੈ। ਦਰਸ਼ਕਾਂ ਨੂੰ ਪਹਿਲਾਂ ਲਿਖ ਲੈਣਾ ਉਸ ਆਮ ਵਹਾਅ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜਿੱਥੇ ਪੂਰਵਦਰਸ਼ਨ URL ਚੁੱਪਚਾਪ ਸਥਾਈ ਹੋ ਜਾਂਦਾ ਹੈ। ਸਮੀਖਿਆ ਵਿੱਚ ਬਾਕੀ ਸਭ ਉਸ ਜਵਾਬ ਉੱਤੇ ਨਿਰਭਰ ਹੈ।
ਜੇ ਕੋਈ ਦਰਸ਼ਕਾਂ ਦਾ ਨਾਂ ਨਹੀਂ ਦੱਸ ਸਕਦਾ, ਤਾਂ ਇਸ ਨੂੰ ਦਸਤਾਵੇਜ਼ੀ ਕਮੀ ਨਹੀਂ ਸਗੋਂ ਪਹਿਲੀ ਖੋਜ ਮੰਨੋ।
ਅੱਗੇ ਦੇ ਦਰਵਾਜ਼ੇ ਅਤੇ ਇਸ ਪਿੱਛੇ ਦੀਆਂ ਸਤਹਾਂ ਵਿੱਚੋਂ ਲੰਘੋ
ਤੁਹਾਨੂੰ ਦਿੱਤੇ ਗਏ URL ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਾਵਾਂ ਦਾ ਹੱਲ ਕਰੋ, ਫਿਰ ਪ੍ਰਸ਼ਾਸਕੀ ਮਾਰਗ ਸਿੱਧੇ ਮੰਗੋ।
dig +short staging.example.com
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/adminਵਾਧੂ ਰਿਕਾਰਡ ਅਕਸਰ ਸਿੱਧਾ-ਸਰੋਤ ਪਤਾ ਦਿਖਾਉਂਦੇ ਹਨ ਜੋ CDN ਜਾਂ VPN ਦਾਖਲੇ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਲੋੜੀਂਦਾ ਨਿਯੰਤਰਣ ਚੋਣਵਾਂ ਹੋ ਜਾਂਦਾ ਹੈ। ਰੀਡਾਇਰੈਕਟ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਐਪ ਕਿੱਥੇ ਰਹਿਣ ਦੀ ਸੋਚਦਾ ਹੈ, ਅਤੇ ਅਣਕਿਆਸੀ ਸਕੀਮ ਜਾਂ ਹੋਸਟਨਾਮ ਅੱਗੇ ਦੀ ਜਾਂਚ ਦਾ ਹੱਕਦਾਰ ਹੈ। ਸੰਭਾਵੀ ਐਡਮਿਨ ਮਾਰਗ ਦੀ ਜਾਂਚ ਕਰਨ ਨਾਲ ਪੰਨਾ ਨਹੀਂ, ਇਨਕਾਰ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਗੈਰ-ਪ੍ਰਮਾਣਿਤ ਪ੍ਰਸ਼ਾਸਕੀ ਮਾਰਗ ਉੱਤੇ 200 ਮਿਲਣਾ ਉਹੀ ਖੋਜ ਹੈ ਜੋ ਪੂਰੀ ਸਮੀਖਿਆ ਲੱਭ ਰਹੀ ਸੀ।
ਵਾਤਾਵਰਨ ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂਚੋ, ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਕਿ ਇਹ ਕੀ ਦਿਖਾਉਂਦਾ ਹੈ
ਲੌਗਿਨ ਮੰਗਣ ਵਾਲਾ ਪੰਨਾ ਵੀ ਬੈਕਐਂਡ ਅਧਿਕਾਰ ਨਾਲ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ। ਪੁੱਛੋ ਕਿ ਵਰਕਲੋਡ ਕਿਸ ਪਛਾਣ ਹੇਠ ਚੱਲਦਾ ਹੈ, ਫਿਰ ਇਸ ਨਾਲ ਜੁੜੀਆਂ ਨੀਤੀਆਂ ਪੜ੍ਹੋ।
aws sts get-caller-identityਉਹ ਕਾਲ ਉਸ ਖਾਤੇ ਅਤੇ ਪ੍ਰਿੰਸੀਪਲ ਦੀ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ ਜੋ ਵਾਤਾਵਰਨ ਅਸਲ ਵਿੱਚ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਹਰ ਅਗਲੇ ਇਜਾਜ਼ਤ ਸਵਾਲ ਦਾ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਹੈ। ਉੱਥੋਂ ਜਾਂਚੋ ਕਿ ਪਛਾਣ ਮੇਲ ਭੇਜ ਸਕਦੀ ਹੈ, ਪੈਸਾ ਹਿਲਾ ਸਕਦੀ ਹੈ, ਉਤਪਾਦਨ ਭੇਦ ਪੜ੍ਹ ਸਕਦੀ ਹੈ ਜਾਂ ਉਤਪਾਦਨ ਡੇਟਾ ਲਿਖ ਸਕਦੀ ਹੈ। ਸਾਂਝੇ ਉਤਪਾਦਨ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਨੂੰ ਸੀਮਿਤ ਸਟੇਜਿੰਗ ਪਛਾਣਾਂ ਨਾਲ ਬਦਲੋ, ਅਤੇ ਜਿੱਥੇ ਹੋਣ ਉੱਥੇ ਵਿਕਰੇਤਾ ਸੈਂਡਬਾਕਸ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਜੋ ਟੈਸਟ ਖਾਤਾ ਅਸਲੀ ਕਾਰਡ ਤੋਂ ਚਾਰਜ ਲੈ ਸਕਦਾ ਹੈ ਉਹ ਵੱਖਰੇ ਹੋਸਟਨਾਮ ਵਾਲਾ ਉਤਪਾਦਨ ਸਿਸਟਮ ਹੈ।
ਸਮੀਖਿਆ ਖ਼ਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ ਸੀਮਾ ਬਣਾਈ ਰੱਖੋ
ਵਾਤਾਵਰਨ ਇੱਕ ਆਡਿਟ ਨਾਲ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੁੰਦਾ; ਇਹ ਅਜਿਹੀ ਮਾਲਕੀ ਨਾਲ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ ਜੋ ਸਟਾਫ਼ ਬਦਲਾਅ ਵਿੱਚ ਟਿਕਦੀ ਹੈ। ਤੈਅ ਕਰੋ ਕਿ ਕੌਣ ਪਹੁੰਚ ਹਟਾਉਂਦਾ ਹੈ, ਟੈਸਟ ਡੇਟਾ ਰੀਸੈਟ ਕਰਦਾ ਹੈ ਅਤੇ ਤੈਨਾਤੀ ਨੂੰ ਸੇਵਾਮੁਕਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਪੂਰਵਦਰਸ਼ਨ ਨੂੰ ਅਜਿਹੀ ਮਿਆਦ ਦਿਓ ਜਿਸ ਨੂੰ ਕਿਸੇ ਨੂੰ ਨਵਿਆਉਣਾ ਪਵੇ। ਅਲੱਗਾਅ ਤਾਂ ਹੀ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦ ਤੱਕ ਅਲੱਗ ਕੀਤੀ ਚੀਜ਼ ਦੀ ਸੰਭਾਲ ਹੁੰਦੀ ਹੈ। ਅਗਲੀ ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ ਉਹੀ ਮਾਰਗ ਦੁਬਾਰਾ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਫੀਚਰ ਫਲੈਗ ਜਾਂ ਨਵਾਂ ਏਕੀਕਰਣ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਇਨਕਾਰ ਕੀਤਾ ਮਾਰਗ ਖੁੱਲ੍ਹਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਮਨਜ਼ੂਰ ਕਾਰਜ ਪ੍ਰਵਾਹ ਅਤੇ ਇਨਕਾਰ ਕੀਤੇ ਪ੍ਰਵਾਹ ਨਾਲ ਡਿਜ਼ਾਈਨ ਸਵੀਕਾਰ ਕਰੋ। ਜੇ ਦੋਵੇਂ ਦਸਤਾਵੇਜ਼ ਅਨੁਸਾਰ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ, ਤਾਂ ਸੀਮਾ ਮੌਜੂਦ ਹੈ; ਜੇ ਸਿਰਫ਼ ਸੁਖਦ ਮਾਰਗ ਦੀ ਜਾਂਚ ਹੋਈ, ਤਾਂ ਇਹ ਇੱਕ ਆਸ ਹੈ।