ਉਪਭੋਗਤਾ ਦੀ ਨਕਲ ਸੁਰੱਖਿਅਤ ਰੱਖੋ: ਸਪੋਰਟ ਪਹੁੰਚ ਲਈ ਗਾਰਡਰੇਲ

ਸਪੋਰਟ ਲਈ ਕਿਸੇ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ ਅਤੇ ਕਿਵੇਂ ਗਲਤ ਹੁੰਦੀ ਹੈ

ਸਪੋਰਟ ਟੀਮਾਂ ਇੰਪਰਸੋਨੇਸ਼ਨ ਦੀ ਮੰਗ ਇਸ ਲਈ ਕਰਦੀਆਂ ਹਨ ਕਿ ਸਕ੍ਰੀਨਸ਼ਾਟ ਅਤੇ ਲੰਬੀਆਂ ਈਮੇਲ ਥ੍ਰੇਡਾਂ ਧੀਮਾ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਜੇ ਇੱਕ ਏਜੰਟ ਉਹੀ ਦੇਖ ਸਕੇ ਜੋ ਗ੍ਰਾਹਕ ਵੇਖਦਾ ਹੈ, ਤਾਂ ਉਹ ਸੈਟਿੰਗਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ ਹੈ, ਏਰਰ ਨੂੰ ਦੁਹਰਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਠੀਕ ਬਟਨ ਜਾਂ ਫੀਲਡ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਉਹ ਵੇਲੇ ਵੀ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਉਪਭੋਗਤਾ ਲੌਕ ਆਊਟ ਹੈ, ਗਲਤ ਸੰਰਚਨਾ ਕਰ ਬੈਠੇ ਹਨ, ਜਾਂ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ ਕਿ ਕੀ ਬਦਲਿਆ।

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

ਜ਼ਿਆਦਾਤਰ ਉਪਭੋਗਤਾ ਤਿੰਨ ਗੱਲਾਂ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ:

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

ਇਹ ਵੀ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਕਿ ਟਰਮ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਪ੍ਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾਵੇ। ਇੰਪਰਸੋਨੇਸ਼ਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਸਪੋਰਟ ਏਜੰਟ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਉਪਭੋਗਤਾ ਦੀ ਐਪ-ਅੰਦਰ ਪਹਚਾਨ ਲੈਂਦਾ ਹੈ ਤਾਂ ਕਿ ਸੰਦਰਭ ਵਿੱਚ ਸਮੱਸਿਆ ਨੂੰ ਦੁਹਰਾਇਆ ਜਾ ਸਕੇ, ਬਲੌਕਾਂ ਅਤੇ ਸਪਸ਼ਟ ਲੇਬਲਿੰਗ ਨਾਲ। ਐਡਮਿਨ ਐਕਸੈੱਸ ਮਤਲਬ ਹੈ ਪ੍ਰਸ਼ਾਸਕੀ ਸ਼ਕਤੀਆਂ ਵਰਤਣਾ (MFA ਰੀਸੈਟ, ਸਬਸਕ੍ਰਿਪਸ਼ਨਾਂ ਸੋਧਣਾ, ਡੇਟਾ ਐਕਸਪੋਰਟ) ਬਿਨਾਂ ਉਪਭੋਗਤਾ ਵਜੋਂ ਦਿਖਾਈ ਦੇਣ ਦੇ। ਦੋਹਾਂ ਨੂੰ ਮਿਲਾ ਦੇਣਾ ਉਹੀ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਬਹੁਤ ਸਾਰੇ "ਸੁਰੱਖਿਅਤ ਉਪਭੋਗਤਾ ਇੰਪਰਸੋਨੇਸ਼ਨ" ਡਿਜ਼ਾਈਨ ਫੇਲ ਹੁੰਦੇ ਹਨ।

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

ਠੀਕ ਲੈਵਲ ਚੁਣੋ (ਦਿਖੋ-ਵਜੋਂ vs ਕਰੋ-ਵਜੋਂ)

ਇਨਪੁਟ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਉਤਪਾਦ ਵਿੱਚ "ਇੰਪਰਸੋਨੇਸ਼ਨ" ਦਾ ਕੀ ਅਰਥ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਨੂੰ ਦੋ ਲੈਵਲ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ:

• ਦਿਖੋ-ਵਜੋਂ (view-as): ਸਪੋਰਟ ਉਹੀ ਦੇਖ ਸਕਦਾ ਜੋ ਉਪਭੋਗਤਾ ਦੇਖਦਾ ਹੈ।
• ਕਰੋ-ਵਜੋਂ (act-as): ਸਪੋਰਟ ਉਪਭੋਗਤਾ ਵੱਲੋਂ ਕਾਰਵਾਈਆਂ ਕਰ ਸਕਦਾ ਹੈ।

ਗਲਤ ਲੈਵਲ ਚੁਣਨ ਨਾਲ ਤੁਸੀਂ ਜਾਂ ਤਾਂ ਟਿਕਟਾਂ ਹੱਲ ਨਹੀਂ ਕਰ ਪਾਓਗੇ, ਜਾਂ ਤਸੀਂ ਅਜਿਹਾ ਪਰਾਈਵੇਸੀ ਜੋਖਮ ਪੈਦਾ ਕਰ ਦਿਆਂਗੇ ਜਿਸਦੀ ਬਾਅਦ ਵਿੱਚ ਵਜ੍ਹਾ ਨਿਹਿਤ ਨਹੀਂ ਬਤਾ ਸਕਦੇ।

ਸਭ ਤੋਂ ਘੱਟ ਖਤਰੇ ਵਾਲੇ ਵਿਕਲਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

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

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

ਪਹਿਲਾਂ ਤੋਂ ਸਫਲਤਾ ਮਾਪਦੰਡ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

ਇੰਪਰਸੋਨੇਸ਼ਨ ਕੋਈ ਫੀਚਰ ਨਹੀਂ ਜੋ "ਸਭ ਕੋਲ ਹੁੰਦਾ ਹੈ" ਵਜੋਂ ਭੇਜ ਦਿਤਾ ਜਾਵੇ। ਉਹ ਨਤੀਜੇ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਮਾਪ ਸਕਦੇ ਹੋ: ਘੱਟ ਬੈਕ-ਅਤੇ-ਫੋਰਥ ਸੁਨੇਹੇ, ਤੇਜ਼ ਰਿਜ਼ੋਲਿਊਸ਼ਨ ਸਮਾਂ, ਅਤੇ ਘੱਟ ਸਪੋਰਟ ਗਲਤੀਆਂ। ਜੇ ਤੁਸੀਂ ਸੁਧਾਰ ਮਾਪ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਅਧਿਕਾਰ ਆਮ ਤੌਰ 'ਤੇ ਵਧਦੇ ਰਹਿੰਦੇ ਹਨ ਜਦ ਤੱਕ ਕੁਝ ਟੁੱਟਦਾ ਨਹੀਂ।

ਸਭ ਤੋਂ ਸੰਵੇਦਨਸ਼ੀਲ ਖੇਤਰ ਨਕਸ਼ਾ ਬਣਾਓ

ਉਹ ਥਾਵਾਂ ਲਿਸਟ ਕਰੋ ਜਿੱਥੇ ਇਕ ਕਲਿੱਕ ਨਾਲ ਅਸਲ ਨੁਕਸਾਨ ਹੋ ਸਕਦਾ ਹੈ: ਨਿੱਜੀ ਸੁਨੇਹੇ, ਭੁਗਤਾਨ, ਪਹਚਾਣ ਅਤੇ ਸੁਰੱਖਿਆ ਸੈਟਿੰਗਾਂ, ਨਿੱਜੀ ਡੇਟਾ ਫੀਲਡ, ਅਤੇ ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਡਾਟਾ ਨਿਰਯਾਤ ਜਾਂ ਮਿਟਾਵੇ ਸਕਦੀ ਹੈ।

ਜੇ ਉਪਭੋਗਤਾ ਕਹਿੰਦਾ ਹੈ "ਮੇਰਾ ਇਨਵੌਇਸ ਗਲਤ ਲੱਗਦਾ ਹੈ," ਤਾਂ ਦਿਖੋ-ਵਜੋਂ ਬਹੁਤ ਵਾਰ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ ਕਿ ਉਹ ਕੀ ਵੇਖਦਾ ਹੈ। ਜੇ ਤੂੰ ਕਰਨਾ-ਵਜੋਂ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਸਿਰਫ਼ ਉਸ ਖਾਸ ਕਿਰਿਆ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ, "ਹਮੇਸ਼ਾਂ ਲਈ ਬਿਲਿੰਗ ਐਡਮਿਨ" ਨਹੀਂ।

ਜੇ ਤੁਸੀਂ ਇਹ ਬਣਾਉਂਦੇ ਹੋ ਕਿਸੇ ਪਲੇਟਫਾਰਮ ਤੇ ਜਿਵੇਂ Koder.ai, ਤਾਂ ਇੰਪਰਸੋਨੇਸ਼ਨ ਨੂੰ ਇੱਕ ਸਮਰੱਥਾ ਵਜੋਂ ਲਵੋ ਜਿਸਦੇ ਲੈਵਲ ਹੋਣ, ਨਾ ਕਿ ਇਕ ਸਿੰਗਲ on/off ਸੁਇਚ। ਇਹ ਬਾਅਦ ਵਿੱਚ ਗਾਰਡਰੇਲ (ਸਕੋਪਸ, ਬੈਨਰ, ਮਨਜ਼ੂਰੀ, ਅਤੇ ਆਡਿਟ) ਨੂੰ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਲਗਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।

ਗਾਰਡਰੇਲ 1: ਡਿਫ਼ॉलਟ ਰੂਪ ਵਿੱਚ ਸੰਕੀਰਣ (narrow) ਸਕੋਪਡ ਪਹੁੰਚ

ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਪਹੁੰਚ ਇਹ ਮੰਨਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਏਜੰਟ ਨੂੰ ਘੱਟ ਦੇਖਣਾ ਅਤੇ ਘੱਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਵੱਧ। ਉਹ ਸਕੋਪ ਜੁੜੇ ਹੋਣ ਜੋ ਦੋਹਾਂ ਉਤਪਾਦ ਖੇਤਰ ਅਤੇ ਨਿਰਧਾਰਤ ਕਾਰਵਾਈਆਂ ਨੂੰ ਵੇਰਵਾ ਦਿੰਦੇ ਹੋਣ। "ਬਿਲਿੰਗ ਇਨਵੌਇਸ ਵੇਖੋ" ਅਤੇ "ਬਿਲਿੰਗ ਪਤਾ ਅਪਡੇਟ ਕਰੋ" ਵੱਖਰੇ ਸਕੋਪ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਭਾਵੇਂ ਉਹ ਇੱਕੋ ਪੇਜ 'ਤੇ ਦਿਸ਼ਤ ਹੋਣ।

ਸਕੋਪਸ ਨੂੰ ਵਾਸਤਵਿਕ ਸਪੋਰਟ ਟਾਸਕਸ ਨਾਲ ਜੋੜ ਕੇ ਰੱਖੋ। ਇੱਕ ਮਜ਼ਬੂਤ ਸਕੋਪ ਮਾਡਲ ਆਮ ਤੌਰ 'ਤੇ ਚਾਰ ਸੀਮਾਵਾਂ ਰੱਖਦਾ ਹੈ:

• ਕਿੱਥੇ: ਉਤਪਾਦ ਖੇਤਰ (ਸੈਟਿੰਗਜ਼, ਪ੍ਰੋਜੈਕਟ, ਇਨਵੌਇਸ, ਸੁਨੇਹੇ)।
• ਕੀ: ਕਾਰਵਾਈਆਂ (ਵੇਖੋ, ਸੋਧੋ, ਰੱਦ ਕਰੋ, ਐਕਸਪੋਰਟ)।
• ਕੋਣ: ਇੱਕ ਨਿਸ਼ਚਿਤ ਟਾਰਗਟ ਉਪਭੋਗਤਾ, "ਇਸ ਵਰਕਸਪੇਸ ਦਾ ਕੋਈ ਵੀ ਉਪਭੋਗਤਾ" ਨਹੀਂ।
• ਕਦੋਂ: ਛੋਟੀ ਸਮਾਂ ਸਕੀਮ।

ਸਮਾਂ ਉਨ੍ਹਾਂ ਦੀ ਤੋਲ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ। ਇੰਪਰਸੋਨੇਸ਼ਨ ਸੈਸ਼ਨ ਮੂਲ ਰੂਪ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਮੁਕੰਮਲ ਹੋ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ (ਅਕਸਰ 10 ਤੋਂ 20 ਮਿੰਟ) ਅਤੇ ਲਗਾਤਾਰ ਨਵੀਂ ਬੇਨਤੀ ਦੀ ਲੋੜ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਹ ਭੁੱਲੇ ਹੋਏ ਟੈਬ ਨੂੰ ਖਾਮੋਸ਼ ਐਕਸੈੱਸ ਵਿੰਡੋ ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।

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

ਗਾਰਡਰੇਲ 2: UI ਵਿੱਚ ਇੰਪਰਸੋਨੇਸ਼ਨ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਾ ਹੋਣ ਦੇਯੋਗ ਬਣਾਓ

ਜੇ ਸਪੋਰਟ ਪ੍ਰਤਿਨਿਧਿ ਭੁੱਲ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਇੰਪਰਸੋਨੇਟ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਇਕ ਸਮੇਂ ਉਹ ਗਲਤ ਕੰਮ ਕਰ ਹੀ ਬੈਠੇਗਾ। ਵਿਜ਼ੀਬਿਲਟੀ ਉਹ ਰੋਜ਼ਾਨਾ ਦੀ ਸੁਰੱਖਿਆ ਨਹੀਂ ਹੈ ਜੋ "ਓਪਸ" ਮੋਮੈਂਟਾਂ ਨੂੰ ਰੋਕਦੀ ਹੈ।

ਇਸ ਸਥਿਤੀ ਨੂੰ ਅਣਦੇਖਾ ਨਹੀਂ ਹੋ ਸਕਣੀ ਬਣਾਓ—ਇੱਕ ਸਥਿਰ ਬੈਨਰ ਜੋ ਹਟਾਇਆ ਨਾ ਜਾ ਸਕੇ। ਇਹ ਹਰ ਪੇਜ 'ਤੇ ਦਿਖਨਾ ਚਾਹੀਦਾ ਹੈ, ਸੈਟਿੰਗਜ਼ ਅਤੇ ਬਿਲਿੰਗ ਸਮੇਤ।

ਉਹ ਬੈਨਰ ਹਮੇਸ਼ਾ ਤਿੰਨ ਚੀਜ਼ਾਂ ਦਿਖਾਉਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਕੌਣ ਨਕਲ ਕਰ ਰਿਹਾ ਹੈ, ਕੌਣ ਨਕਲ ਹੋ ਰਿਹਾ ਹੈ, ਅਤੇ ਸੈਸ਼ਨ ਕਿਉਂ ਹੈ (ਟਿਕਟ ਨੰਬਰ ਜਾਂ ਕੇਸ)। "ਕਿਉਂ" ਅੱਗੇ ਰਿਵਿਊਅਰਾਂ ਨੂੰ ਪਿਛੋਂ ਸੰਦਰਭ ਦਿੰਦਾ ਹੈ।

ਸਿਰਫ਼ ਹੈਡਰ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ। ਪੂਰੇ UI ਵਿੱਚ ਇੱਕ ਸਪਸ਼ਟ ਵਿਜ਼ੂਅਲ ਬਦਲਾਅ (ਰੰਗ ਬਦਲਣਾ, ਬਾਰਡਰ, ਵੱਖਰਾ ਫਰੇਮ) ਵਰਤੋ ਤਾਂ ਜੋ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਪਛਾਣਯੋਗ ਹੋ ਜਾਵੇ।

"ਇੰਪਰਸੋਨੇਸ਼ਨ ਛੱਡੋ" ਬੈਨਰ ਵਿੱਚ ਰੱਖੋ। ਇਸ ਨੂੰ ਮਿਨੂ ਵਿੱਚ ਲੁਕਾਓ ਨਾ। ਛੱਡਣਾ ਜਾਰੀ ਰੱਖਣ ਨਾਲ ਤੇਜ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਜੇ ਸੈਸ਼ਨ ਸਮਾਂ-ਸੀਮਿਤ ਹਨ, ਤਾਂ ਕਾਉਂਟਡਾਉਨ ਟਾਈਮਰ ਦਿਖਾਓ। ਇਹ ਲੰਬੇ ਸੈਸ਼ਨਾਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਤਾਜ਼ਾ ਸੈਸ਼ਨ (ਤੇ ਤਾਜ਼ੀ ਮਨਜ਼ੂਰੀ) ਦੀ ਬੇਨਤੀ ਕਰਨ ਲਈ ਉਕਸਾਉਂਦਾ ਹੈ।

ਗਾਰਡਰੇਲ 3: ਉੱਚ ਪਹੁੰਚ ਲਈ ਮਨਜ਼ੂਰੀ ਪ੍ਰਵਾਹ

ਅਧਿਕਾਂਸ਼ ਸਪੋਰਟ ਕੰਮਾਂ ਨੂੰ ਪੂਰੀ ਤਾਕਤ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਮਨਜ਼ੂਰੀ ਫਲੋ ਉੱਚ ਪਹੁੰਚ ਨੂੰ ਕਮੀ, ਦਿੱਖਯੋਗ ਅਤੇ ਸਮਾਂ-ਬੰਨ੍ਹਿਤ ਰੱਖਦੇ ਹਨ।

ਹਰ ਸੈਸ਼ਨ ਲਈ ਇੱਕ ਕਾਰਨ ਲਾਜ਼ਮੀ ਕਰੋ, ਭਾਵੇਂ ਘੱਟ ਜੋਖਮ ਵਾਲੇ ਹੋਣ। ਇਸਨੂੰ ਛੋਟਾ ਤੇ ਢਾਂਚਾਬੱਧ ਰੱਖੋ ਤਾਂ ਜੋ ਲੋਕ ਧੁੰਦਲੇ ਨੋਟਾਂ ਵਿੱਚ ਲੁਕ ਨਾ ਸਕਣ।

"ਕਿਉਂ" ਅਤੇ "ਕਿੰਨਾ ਸਮਾਂ" ਗੈਰ-ਵਿਕਲਪੀ ਬਣਾਓ

ਇੱਕ ਚੰਗਾ ਬੇਨਤੀ ਫਾਰਮ ਮਨਜ਼ੂਰਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਆਡਿਟ ਨੂੰ ਮਾਇਨੇਦਾਰ ਬਣਾਉਂਦਾ ਹੈ। ਘੱਟੋ-ਘੱਟ, ਟਿਕਟ ਜਾਂ ਕੇਸ ID, ਮੰਗਿਆ ਗਿਆ ਸਕੋਪ, ਮਿਆਦ, ਇੱਕ ਛੋਟਾ ਕਾਰਨ (ਸ਼੍ਰੇਣੀ + ਇੱਕ ਵਾਕ), ਅਤੇ ਕੀ ਉਪਭੋਗਤਾ ਜਾਂ ਅਕਾਊਂਟ ਮਾਲਕ ਨੂੰ ਸੂਚਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ—ਇਹ ਸਭ ਕੈਪਚਰ ਕਰੋ।

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

"ਬ੍ਰੇਕ-ਗਲਾਸ" ਲਈ ਦੋ-ਅਦਮੀ ਨੀਤੀ

ਕੁਝ ਕਾਰਵਾਈਆਂ ਐਨੀ ਖਤਰਨਾਕ ਹੁੰਦੀਆਂ ਹਨ ਕਿ ਉਹਨਾਂ ਲਈ ਦੋ ਲੋਕਾਂ ਦੀ ਲੋੜ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: ਇੱਕ ਬੇਨਤੀ ਕਰਨ ਲਈ, ਇੱਕ ਮਨਜ਼ੂਰ ਕਰਨ ਲਈ। ਇਨ੍ਹਾਂ ਨੂੰ ਰੇਅਰ ਅਤੇ ਜਲੰਦੀ ਮੰਨੋ, ਸੁਵਿਧਾ ਨਹੀਂ।

ਬ੍ਰੇਕ-ਗਲਾਸ ਕਾਰਵਾਈਆ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਵੱਡੇ ਡੈਟਾਸੈਟ ਐਕਸਪੋਰਟ, MFA ਰੀਸੈਟ ਜਾਂ ਖਾਤੇ ਦੀ ਮਾਲਕੀ ਬਦਲਣਾ, ਅਤੇ ਐਡਮਿਨ ਰੋਲ ਜਾਂ ਸੁਰੱਖਿਆ ਸੈਟਿੰਗਾਂ ਸੋਧਣਾ ਸ਼ਾਮਿਲ ਹੈ।

ਮਨਜ਼ੂਰੀਆਂ ਆਪਣੇ ਆਪ ਮੁਕੰਮਲ ਹੋ ਜਾਣ—ਜੇ ਕੰਮ ਸਮੇਂ 'ਚ ਨਹੀਂ ਹੋਇਆ, ਤਾਂ ਏਜੰਟ ਨੂੰ ਮੁੜ ਬੇਨਤੀ ਕਰਨੀ ਪਏਗੀ। ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲਾ ਪੂਲ ਛੋਟਾ ਰੱਖੋ (ਟੀਮ ਲੀਡ, ਸੁਰੱਖਿਆ, ਆਨ-ਕਾਲ ਮੈਨੇਜਰ) ਅਤੇ ਛੁਟੀਆਂ ਸਪਸ਼ਟ ਰੱਖੋ।

ਅਖ਼ਿਰ ਵਿੱਚ, ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾ ਜਾਂ ਅਕਾਊਂਟ ਮਾਲਕ ਨੂੰ ਕਦੋਂ ਸੂਚਿਤ ਕਰਨਾ ਹੈ। ਕਈ ਮਾਮਲਿਆਂ ਵਿੱਚ, "ਸਪੋਰਟ ਨੇ ਤੁਹਾਡੇ ਖਾਤੇ ਨੂੰ ਟਿਕਟ #12345 ਹੱਲ ਕਰਨ ਲਈ ਐਕਸੈੱਸ ਕੀਤਾ" ਵਰਗਾ ਸਧਾਰਨ ਨੋਟਿਸ ਕਾਫੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਤੁਰੰਤ ਸੂਚਿਤ ਨਹੀਂ ਕਰ ਸਕਦੇ (ਉਦਾਹਰਣ ਦੇ ਲਈ, ਸੰਭਾਵਤ ਖਾਤਾ ਹਾਈਜੈਕ), ਤਾਂ ਲਿਖਤੀ ਛੋਟ ਦਾ ਤੱਕਾਜ਼ਾ ਕਰੋ ਅਤੇ ਛੋਟੀ ਮਨਜ਼ੂਰੀ ਵਿੰਡੋ ਰੱਖੋ।

ਗਾਰਡਰੇਲ 4: ਐਸੇ ਆਡਿਟ ਇਵੈਂਟ ਜੋ ਧਿਆਨ ਉਠਾ ਸਕਦੇ ਹਨ

ਜੇ ਕਦੇ ਇੰਪਰਸੋਨੇਸ਼ਨ ਸਮੱਸਿਆ ਬਣਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਆਡਿਟ ਲੌਗ ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਹੋਇਆ। ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਪੰਜ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਵੇ: ਕਿਸਨੇ ਕੀਤਾ, ਕਿਸ ਨੂੰ ਕੀਤਾ, ਕਿਉਂ, ਉਹਨੂੰ ਕੀ ਪਹੁੰਚ ਦਿੱਤੀ ਗਈ ਸੀ, ਅਤੇ ਉਹਨਾਂ ਨੇ ਕੀ ਬਦਲਿਆ।

ਸ਼ੁਰੂਆਤ ਸੈਸ਼ਨ ਲੌਗਿੰਗ ਨਾਲ ਕਰੋ: ਸ਼ੁਰੂ ਅਤੇ ਖਤਮ ਦਾ ਸਮਾਂ, ਸਪੋਰਟ ਏਜੰਟ (ਐਕਟਰ), ਗ੍ਰਾਹਕ (ਟਾਰਗੇਟ), ਦਿੱਤਾ ਗਿਆ ਸਕੋਪ, ਅਤੇ ਦਿੱਤਾ ਗਿਆ ਕਾਰਨ। ਇਸਨੂੰ ਸਪੋਰਟ ਟਿਕਟ ਜਾਂ ਕੇਸ ID ਨਾਲ ਜੋੜੋ।

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

ਜੋ metadata ਰੀਕਨਸਟਰਕਟ ਕਰਨ ਲਈ ਕਾਫੀ ਹੋਵੇ ਉਹ ਸ਼ਾਮਿਲ ਕਰੋ: ਟਾਈਮਸਟੈਂਪ, IP ਐਡਰੈੱਸ, ਡਿਵਾਈਸ ਜਾਂ ਯੂਜ਼ਰ-ਏਜੈਂਟ, ਮਹੌਲ (prod vs staging), ਅਤੇ ਝੋਟਿਆ ਗਿਆ ਵਸਤੂ (ਕਿਹੜਾ ਇਨਵੌਇਸ, ਕਿਹੜੀ ਭੂਮਿਕਾ, ਕਿਹੜਾ ਉਪਭੋਗਤਾ)। ਹਰ ਇਵੈਂਟ ‘ਤੇ ਦੋਨੋ ਪਹਿਚਾਨਾਂ ਨੂੰ ਸਟੋਰ ਕਰੋ: ਐਕਟਰ (ਸਪੋਰਟ ਏਜੰਟ) ਅਤੇ ਪ੍ਰਭਾਵੀ ਉਪਭੋਗਤਾ (ਜਿਸ ਦੀ ਨਕਲ ਕੀਤੀ ਗਈ)।

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

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

ਗਾਰਡਰੇਲ 5: ਡੇਟਾ ਘਟਾਓ ਅਤੇ ਕਾਰਵਾਈਆਂ ਦੀ ਸੀਮਾ ਰੱਖੋ

ਇੰਪਰਸੋਨੇਸ਼ਨ ਉਸ ਸਭ ਤੋਂ ਘੱਟ ਡੇਟਾ ਦਿਖਾਉਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਹੈ। ਮਕਸਦ ਹੈ ਸਪੋਰਟ ਤੇਜ਼ੀ ਬਿਨਾਂ ਹਰ ਸੈਸ਼ਨ ਨੂੰ ਪੂਰੇ ਖਾਤੇ ਦੀ ਪਹੁੰਚ ਵਿੱਚ ਬਦਲੇ।

ਸਭ ਤੋਂ ਸੰਵੇਦਨਸ਼ੀਲ ਫੀਲਡਸ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਮਾਸਕ ਕਰੋ, ਭਾਵੇਂ ਏਜੰਟ ਅਸਲ UI ਦੇਖ ਰਿਹਾ ਹੋਵੇ। ਖੋਲ੍ਹਣਾ ਇਕ ਇਰਾਦੇ ਵਾਲੀ ਕਾਰਵਾਈ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸਦਾ ਸਪਸ਼ਟ ਕਾਰਨ ਦਰਜ ਕੀਤਾ ਜਾਵੇ। ਆਮ ਉਦਾਹਰਨਾਂ ਵਿੱਚ API ਕੀਆਂ ਅਤੇ ਰਿਕਵਰੀ ਕੋਡ, ਪੂਰੇ ਭੁਗਤਾਨ ਵੇਰਵੇ (ਸਿਰਫ਼ ਆਖਰੀ 4 ਅੰਕ ਦਿਖਾਓ), ਅਤੇ ਬਹੁਤ ਗੁਪਤ ਨਿੱਜੀ ਡੇਟਾ ਸ਼ਾਮਿਲ ਹਨ।

ਅਗਲਾ, ਉਹ ਕਾਰਵਾਈਆਂ ਰੋਕੋ ਜੋ ਉਪਭੋਗਤਾ ਨੂੰ ਲੌਕ ਆਊਟ ਕਰ ਸਕਦੀਆਂ ਹਨ ਜਾਂ ਮਾਲਕੀ ਬਦਲ ਸਕਦੀਆਂ ਹਨ। ਇੰਪਰਸੋਨੇਸ਼ਨ ਮੋਡ ਵਿੱਚ, ਆਮ ਤੌਰ 'ਤੇ "ਤਸ਼ਖੀਸ ਅਤੇ ਠੀਕ ਕਰੋ" ਕਾਰਵਾਈਆਂ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨਾ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ (ਜਿਵੇਂ ਫੇਲ ਹੋਈ ਸਿੰਕ ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ) ਪਰ ਪਹਚਾਣ ਅਤੇ ਪੈਸੇ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਮਨਾਓ।

ਡੇਟਾ ਐਕਸਪੋਰਟ ਇੱਕ ਹੋਰ ਆਮ ਫੁਟਗਨ ਹੈ। ਬਲਕ ਡਾਊਨਲੋਡ (CSV ਐਕਸਪੋਰਟ, ਇਨਵੌਇਸ, ਚੈਟ ਲੌਗ, ਅਟੈਚਮੈਂਟ) ਨੂੰ ਅਣੁਮੋਦਨ ਤੱਕ ਅਪਾਹਜ ਕਰੋ ਜਦ ਤੱਕ ਟਿਕਟ ਨਾਲ ਜੁੜੀ ਵੱਖਰੀ ਮਨਜ਼ੂਰੀ ਅਤੇ ਛੋਟੀ ਸਮਾਂ-ਵਿੰਡੋ ਨਾਹ ਹੋਵੇ।

ਅਖ਼ਿਰ ਵਿੱਚ, ਹਾਰਡ ਲਿਮਿਟ ਲਗਾਓ ਤਾਂ ਜੋ ਇੱਕ ਚੰਗੇ ਇਰਾਦੇ ਵਾਲਾ ਏਜੰਟ ਵੀ ਜ਼ਿਆਦਾ ਦਾਇਰਿਆਂ ਵਿੱਚ ਨਾ ਜਾ ਸਕੇ: ਛੋਟੀ ਸੈਸ਼ਨ ਟਾਈਮਆਊਟ, ਇੰਪਰਸੋਨੇਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨ ਤੇ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ 'ਤੇ ਰੇਟ ਸੀਮਾ, ਇਕ ਸਮੇਂ ਇਕ ਐਕਟਿਵ ਸੈਸ਼ਨ, ਅਤੇ ਬਾਰ-ਬਾਰ ਨਾਕਾਮ ਕੋਸ਼ਿਸ਼ਾਂ ਤੋਂ ਬਾਅਦ ਕੁਛժ ਠੰਡਾ ਸਮਾਂ।

ਜੇ ਤੁਹਾਡੀ ਸਪੋਰਟ ਪ੍ਰਕਿਰਿਆ ਸਕ੍ਰੀਨਸ਼ਾਟਸ ਜਾਂ ਸਕ੍ਰੀਨ ਰਿਕਾਰਡਿੰਗਾਂ ਵਰਤਦੀ ਹੈ, ਤਾਂ ਉਹਨਾਂ 'ਤੇ ਵੀ ਉਹੀ ਘਟਾਓ ਲਾਗੂ ਕਰੋ। ਮਾਸਕਿੰਗ ਲਾਗੂ ਕਰੋ, ਟਿਕਟ ਸੰਦਰਭ ਦੀ ਲੋੜ ਰੱਖੋ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸਭ ਤੋਂ ਛੋਟੀ ਸਮਾਂ ਲਈ ਸਟੋਰ ਕਰੋ।

ਇਸਨੂੰ ਬਣਾਉਣ ਦਾ ਤਰੀਕਾ: ਇੱਕ ਸਧਾਰਣ ਕਦਮ-ਦਰ-ਕਦਮ ਖਾਕਾ

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

1. ਰੋਲਾਂ ਅਤੇ "ਕੌਣ ਕੀ ਕਰ ਸਕਦਾ ਹੈ" ਨਿਰਧਾਰਤ ਕਰੋ। ਆਮ ਰੋਲ ਹਨ: ਸਪੋਰਟ ਏਜੰਟ, ਸੁਪਰਵਾਈਜ਼ਰ, ਸੁਰੱਖਿਆ, ਅਤੇ ਐਡਮਿਨ। ਫ਼ੈਸਲਾ ਕਰੋ ਕਿ ਕੌਣ ਇੰਪਰਸੋਨੇਸ਼ਨ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ, ਕੌਣ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੌਣ ਸਿਰਫ਼ ਲੌਗ ਰਿਵਿਊ ਕਰ ਸਕਦਾ ਹੈ।

2. ਇੱਕ ਪਰਮਿਸ਼ਨ ਮੈਟ੍ਰਿਕਸ ਲਿਖੋ ਜੋ ਅਸਲੀ ਟਾਸਕਸ ਨਾਲ ਮੇਲ ਖਾਏ। "ਸਭ ਉਪਭੋਗਤਾ ਡੇਟਾ" ਤੋਂ ਬਚੋ। "ਬਿਲਿੰਗ ਰੀਡ", "ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਰੱਦ", "MFA ਰੀਸੈਟ", ਜਾਂ "ਕਰੀਂਟ ਐਰਰ ਵੇਖੋ" ਵਰਗੇ ਸਕੋਪ ਪਸੰਦ ਕਰੋ। ਡਿਫ਼ੋਲਟ ਸਕੋਪ ਛੋਟਾ ਰੱਖੋ।

3. ਸਰਵਰ ਉੱਤੇ ਇੱਕ ਇੰਪਰਸੋਨੇਸ਼ਨ ਸੈਸ਼ਨ ਆਬਜੈਕਟ ਬਣਾਓ। ਕਾਰਨ, ਟਾਰਗਟ ਉਪਭੋਗਤਾ, ਅਨੁਮਤ ਸਕੋਪ, ਅਤੇ ਇੱਕ ਕਠੋਰ ਮਿਆਦ ਲਾਜ਼ਮੀ ਕਰੋ। ਇਸਨੂੰ ਸਧਾਰਣ ਲੌਗਇਨ ਸੈਸ਼ਨਾਂ ਤੋਂ ਵੱਖਰਾ ਚਲਾਓ।

4. ਹਰ ਇਕ ਬੇਨਤੀ 'ਤੇ ਸਕੋਪ ਚੈੱਕਸ ਸਰਵਰ-ਸਾਈਡ ਅਮਲ ਕਰੋ। UI 'ਤੇ ਬਟਨ ਛੁਪਾਉਣ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ। ਹਰ ਸੰਵੇਦਨਸ਼ੀਲ ਏਂਡਪੋਇੰਟ ਨੂੰ ਇੱਕ ਸਰਵਰ-ਪੱਖੀ ਜਾਂਚ ਨਾਲ ਕਿਸੇ ਸਰਗਰਮ, ਅਵਧੀ-ਅਪ-ਡੇਟ ਸੈਸ਼ਨ, ਮਨਜ਼ੂਰ ਸਕੋਪ, ਅਤੇ ਕਿ ਸਟਾਫ਼ ਮੈਂਬਰ ਦੇ ਕੋਲ ਅਜੇ ਵੀ ਸਹੀ ਰੋਲ ਹੈ ਇਹ ਸਾਬਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

5. ਇਸਨੂੰ ਸਪਸ਼ਟ ਅਤੇ ਆਡੀਟेबल ਬਣਾਓ। ਨਕਲ ਕਰ ਰਹੇ ਸਮੇਂ ਹਰ ਪੇਜ 'ਤੇ ਇੱਕ ਸਥਿਰ ਬੈਨਰ ਜੋੜੋ, ਇਕ-ਕਲਿੱਕ ਐਕਜ਼ਿਟ ਸ਼ਾਮਿਲ ਕਰੋ, ਅਤੇ ਸੈਸ਼ਨ ਸ਼ੁਰੂ/ਅਖੀਰ ਅਤੇ ਕੋਈ ਵੀ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈ ਲੌਗ ਕਰੋ।

ਜੇ ਤੁਸੀਂ ਐਪਸ Koder.ai 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਉਹੀ ਸਿਧਾਂਤ ਰੱਖੋ: ਸਕੋਪਸ ਅਤੇ ਆਡਿਟ ਇਵੈਂਟਸ ਬੈਕਐਂਡ ਚੈੱਕਾਂ ਵਿੱਚ ਰਹਿਣ, ਸਿਰਫ਼ ਜਨਰੇਟ ਕੀਤੇ UI ਲਾਜਿਕ ਵਿੱਚ ਨਹੀਂ।

ਉਦਾਹਰਣ ਦਾ ਦ੍ਰਿਸ਼: ਬਿਨਾਂ ਅਤੈਕੇ ਦੇ ਬਿਲਿੰਗ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨਾ

ਇੱਕ ਗਾਹਕ ਲਿਖਦਾ ਹੈ: ਉਹ ਪਿਛਲੇ ਮਹੀਨੇ ਦਾ ਚਾਰਜ ਵੇਖ ਸਕਦਾ ਹੈ, ਪਰ ਉਹਨਾਂ ਦਾ ਇਨਵੌਇਸ ਗਾਇਬ ਹੈ ਅਤੇ ਰਸੀਦ ਡਾਊਨਲੋਡ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ। ਅਨੁਮਾਨ ਲਾਉਣਾ ਧੀਮਾ ਹੈ; ਜੋ ਗ੍ਰਾਹਕ ਵੇਖਦਾ ਹੈ ਉਹ ਦੀ ਪੁਸ਼ਟੀ ਤੇਜ਼ ਹੈ।

ਏਜੰਟ ਉਸ ਇਕ ਖਾਤੇ ਲਈ ਦਿਖੋ-ਵਜੋਂ ਇੰਪਰਸੋਨੇਸ਼ਨ ਸੈਸ਼ਨ ਮੰਗਦਾ ਹੈ। ਉਹ ਕਾਰਨ ਦੇ ਦੇਂਦਾ ਹੈ: "ਟਿਕਟ #18422 ਲਈ ਇਨਵੌਇਸ ਵਿਜ਼ੀਬਿਲਿਟੀ ਅਤੇ ਰਸੀਦ ਡਾਊਨਲੋਡ ਏਰਰ ਦੀ ਪੁਸ਼ਟੀ।" ਬੇਨਤੀ ਸੰਕੀਰਣ ਹੈ: ਬਿਲਿੰਗ ਸਕਰੀਨਾਂ ਦੀ ਰੀਡ ਪਹੁੰਚ, ਭੁਗਤਾਨ ਮੈਥਡ ਬਦਲਣ ਦੀ ਸਮਰੱਥਾ ਨਹੀਂ, ਅਤੇ ਸੰਬੰਧਿਤ ਖੇਤਰਾਂ ਤੋਂ ਅਣਸੰਬੰਧਤ ਇਲਾਕਿਆਂ (ਜਿਵੇਂ ਸੁਨੇਹੇ ਜਾਂ ਫਾਇਲਾਂ) ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ।

ਕਿਉਂਕਿ ਇਨਵੌਇਸ ਸੰਵੇਦਨਸ਼ੀਲ ਹਨ, ਬੇਨਤੀ ਸੁਪਰਵਾਇਜ਼ਰ ਕੋਲ ਮਨਜ਼ੂਰ ਲਈ ਭੇਜੀ ਜਾਂਦੀ ਹੈ। ਸੁਪਰਵਾਇਜ਼ਰ ਸਕੋਪ, ਕਾਰਨ, ਅਤੇ ਮਿਆਦ (ਉਦਾਹਰਣ ਲਈ 15 ਮਿੰਟ) ਦੀ ਸਮੀਖਿਆ ਕਰਦਾ ਹੈ ਅਤੇ ਮਨਜ਼ੂਰੀ ਦੇ ਦਿੰਦਾ ਹੈ।

ਜਦ ਏਜੰਟ ਖਾਤਾ ਖੋਲ੍ਹਦਾ ਹੈ, ਇੱਕ ਚਮਕਦਾਰ ਬੈਨਰ ਸਪਸ਼ਟ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਉਹ ਉਪਭੋਗਤਾ ਵਜੋਂ ਕਾਰਵਾਈ ਕਰ ਰਿਹਾ ਹੈ, ਸਕੋਪ ਅਤੇ ਕਾਉਂਟਡਾਉਨ ਟਾਈਮਰ ਸਮੇਤ। ਇਹ ਹੀ ਸੁਰੱਖਿਅਤ ਉਪਭੋਗਤਾ ਇੰਪਰਸੋਨੇਸ਼ਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਸਪਸ਼ਟ, ਅਸਥਾਈ, ਅਤੇ ਗਲਤ ਵਰਤੋਂ ਲਈ ਮੁਸ਼ਕਲ।

ਏਜੰਟ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਇਨਵੌਇਸ ਮੌਜੂਦ ਹੈ ਪਰ ਖਾਤਾ "ਕੇਵਲ ਈਮੇਲ ਇਨਵੌਇਸ" 'ਤੇ ਸੈਟ ਹੈ, ਅਤੇ ਰਸੀਦ ਡਾਊਨਲੋਡ ਬਿਲਿੰਗ अनुमਤੀਆਂ ਦੁਆਰਾ ਰੋਕਿਆ ਗਿਆ ਹੈ। ਉਹ ਇੰਪਰਸੋਨੇਸ਼ਨ ਦੌਰਾਨ ਕੁਝ ਵੀ ਬਦਲਦਾ ਨਹੀਂ। ਇਸ ਦੀ ਬਜਾਏ, ਉਹ ਇੰਪਰਸੋਨੇਸ਼ਨ ਛੱਡਦਾ ਹੈ ਅਤੇ ਆਮ ਸਪੋਰਟ ਪੈਨਲ 'ਚ ਵੱਖਰੇ ਐਡਮਿਨ ਕਾਰਵਾਈ ਵਜੋਂ ਫਿਕਸ ਲਗਾਉਂਦਾ ਹੈ।

ਬਾਅਦ ਵਿੱਚ, ਆਡਿਟ ਟਰੇਲ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ: ਕਿਸਨੇ ਪਹੁੰਚ ਦੀ ਮੰਗ ਕੀਤੀ, ਕਿਸਨੇ ਮਨਜ਼ੂਰ ਕੀਤੀ, ਕਦੋਂ ਇੰਪਰਸੋਨੇਸ਼ਨ ਸ਼ੁਰੂ ਅਤੇ ਖਤਮ ਹੋਈ, ਕਿਹੜਾ ਸਕੋਪ ਦਿੱਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਕਿਹੜੀਆਂ ਐਡਮਿਨ ਤਬਦੀਲੀਆਂ ਸੈਸ਼ਨ ਤੋਂ ਬਾਹਰ ਕੀਤੀਆਂ ਗਈਆਂ।

ਉਹ ਆਮ ਗਲਤੀਆਂ ਜੋ ਗੋਪਨਯਤਾ ਦੀਆਂ ਦੁਰਘਟਨਾਵਾਂ ਵਲ ਲੈ ਜਾਂਦੀਆਂ ਹਨ

ਜ਼ਿਆਦਾਤਰ ਪਰਾਈਵੇਸੀ ਫੇਲ ਇੰਪਰਸੋਨੇਸ਼ਨ ਨਾਲ ਕੋਈ ਨਵਾਂ ਹੈਕ ਨਹੀਂ ਹੁੰਦੇ। ਇਹ ਸਾਂਝੇ ਛੋਟੇ-ਛੋਟੇ ਸ਼ਾਰਟਕਟ ਹਨ ਜੋ ਮਦਦਗਾਰ ਫੀਚਰ ਨੂੰ ਇੱਕ ਸਭ-ਪਹੁੰਚ ਬੈਕਡੋਰ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ।

ਇਕ ਫੜ ਇਹ ਹੈ ਕਿ ਸੁਰੱਖਿਆ ਨੂੰ ਸਿਰਫ़ UI ਦੀ ਸਮੱਸਿਆ ਸਮਝ ਲਿਆ ਜਾਵੇ। ਜੇ ਕੋਈ ਫਰੰਟ-ਐਂਡ ਫਲੈਗ ਫਲਿੱਪ ਕਰਕੇ (ਜਾਂ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ ਰਿਕਵੇਸਟ ਟਵੀਕ ਕਰਕੇ) ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਅਸਲ ਕੰਟਰੋਲ ਨਹੀਂ ਹੈ। ਲਾਗੂਕੀਰਨ ਹਰ ਰਿਕਵੇਸਟ 'ਤੇ ਸਰਵਰ-ਸਾਈਡ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਹੋਰ ਇਕ ਆਮ ਫੇਲ੍ਹ ਇਹ ਹੈ ਕਿ "ਸੁਰੱਖਿਅਤ ਉਪਭੋਗਤਾ ਇੰਪਰਸੋਨੇਸ਼ਨ" ਨੂੰ ਇਕ ਇਕਲ ਮੋਡ ਵਜੋਂ ਬਣਾਉਣਾ ਜੋ ਆਪਣੇ ਆਪ ਉਪਭੋਗਤਾ ਦੀਆਂ ਸਾਰੀਆਂ ਸ਼ਕਤੀਆਂ ਨੂੰ ਵਾਰਸਾਂ ਲੈਂਦਾ ਹੈ। ਸਪੋਰਟ ਵਿਰਲੇ ਹੀ ਪੂਰੀ ਤਾਕਤ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜਦ ਇੰਪਰਸੋਨੇਸ਼ਨ ਨੂੰ ਸਾਰਾ ਡੇਟਾ ਦੇਖਣ, ਕੋਈ ਵੀ ਸੈਟਿੰਗ ਸੋਧਣ, ਅਤੇ ਕੁਝ ਵੀ ਐਕਸਪੋਰਟ ਕਰਨ ਦੀ ਆਗਿਆ ਮਿਲ ਜਾਏ, ਤਾਂ ਇੱਕ ਗਲਤੀ ਜਾਂ ਇੱਕ ਸਮਝੌਤਾ ਕੀਤਾ ਸਪੋਰਟ ਖਾਤਾ ਇੱਕ ਵੱਡੀ ਘਟਨਾ ਬਣ ਸਕਦਾ ਹੈ।

ਕੁਝ ਮੁੜ-ਦੋਹਰਾਉਂਦੀਆਂ ਪੈਟਰਨ ਹਨ: ਡਿਫ਼ੋਲਟ ਰੂਪ ਵਿੱਚ ਪੂਰੀ ਪਹੁੰਚ, ਕਦੇ ਨਾ ਮਿੱਲਣ ਵਾਲੀਆਂ ਸੈਸ਼ਨ, ਬੈਨਰ ਜੋ ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਜਾਂਦੇ ਹਨ, ਆਡਿਟ ਲੌਗ ਜੋ ਸਿਰਫ਼ ਸ਼ੁਰੂ/ਅਖੀਰ ਕੈਪਚਰ ਕਰਦੇ ਹਨ (ਨ ਕਿ ਕਾਰਵਾਈਆਂ), ਅਤੇ ਇੰਪਰਸੋਨੇਸ਼ਨ ਦੌਰਾਨ ਮਨਜ਼ੂਰ ਉੱਚ-ਖਤਰੇ ਕਾਰਵਾਈਆਂ।

ਇੱਕ ਵਿਹਾਰਕ ਨਿਯਮ ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ: ਜੇ ਕੋਈ ਕਾਰਵਾਈ ਗਲਤ ਹੱਥਾਂ ਵਿੱਚ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੀ ਹੈ, ਤਾਂ ਮੁਲ ਰੂਪ ਵਿੱਚ ਉਸਨੂੰ ਇੰਪਰਸੋਨੇਸ਼ਨ ਮੋਡ ਵਿਚ ਰੋਕੋ ਅਤੇ ਉਸਨੂੰ ਕਰਨ ਲਈ ਇੱਕ ਵੱਖਰਾ, ਵਾਜਬੀ ਵਰਕਫਲੋ ਬਲਾਈ ਕਰੋ।

ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ

ਇੰਪਰਸੋਨੇਸ਼ਨ ਓਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ "ਸਭ ਤੋਂ ਖਰਾਬ ਦਿਨ" ਸੋਚ ਰੱਖ ਕੇ ਆਖ਼ਰੀ ਜਾਂਚ ਕਰੋ: ਇੱਕ ਜਲਦੀ ਕਰ ਰਹਾ ਏਜੰਟ, ਇੱਕ ਜिज्ञਾਸੂ ਸਾਥੀ, ਜਾਂ ਇੱਕ ਸਮਝੌਤਾ ਕੀਤਾ ਐਡਮਿਨ।

• ਸਕੋਪ ਡਿਫ਼ੌਲਟ ਰੂਪ ਵਿੱਚ ਸੰਕੀਰਣ: ਇਕ ਸਮੇਂ ਇੱਕ ਟਾਰਗਟ ਉਪਭੋਗਤਾ, ਅਤੇ ਕੇਵਲ ਜ਼ਰੂਰੀ ਉਤਪਾਦ ਖੇਤਰ।
• ਹਰ ਸੈਸ਼ਨ ਲਈ ਲਿਖਤੀ ਕਾਰਨ ਲਾਜ਼ਮੀ ਅਤੇ ਆਟੋ-ਐਕਸਪਾਇਰ ਹੋਵੇ।
• UI ਸਪਸ਼ਟ ਹੋਵੇ: ਹਰ ਪੇਜ 'ਤੇ ਇੱਕ ਸਥਿਰ ਬੈਨਰ ਜੋ ਐਕਟਰ, ਟਾਰਗੇਟ, ਅਤੇ ਮਿਆਦ ਦਿਖਾਏ।
• ਉੱਚ-ਖਤਰੇ ਸਕੋਪਾਂ ਲਈ ਮਨਜ਼ੂਰੀ ਲਾਜ਼ਮੀ ਹੋਵੇ, ਖ਼ਾਸ ਕਰ ਕੇ ਪੈਸਾ, ਪਰਮਿਸ਼ਨ, ਜਾਂ ਐਕਸਪੋਰਟ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਲਈ।
• ਆਡਿਟ ਲੌਗ ਐਕਟਰ, ਟਾਰਗੇਟ, ਸਕੋਪ, ਕਾਰਨ, ਟਾਈਮਸਟੈਂਪ, IP/ਡਿਵਾਈਸ ਇਸ਼ਾਰੇ, ਅਤੇ ਕੀਤੇ ਗਏ ਅਕਸ਼ੀ ਤਬਦੀਲੀਆਂ ਨੂੰ ਕੈਪਚਰ ਕਰੇ।

ਐਸਕੇਪ ਹੈਚ: ਇੱਕ-ਕਲਿੱਕ "ਇੰਪਰਸੋਨੇਸ਼ਨ ਛੱਡੋ" ਜੋ ਐਪ ਐਰਰ ਹੋਣ 'ਤੇ ਵੀ ਕੰਮ ਕਰੇ, ਜਾਂਚੋ।

ਕਠੋਰ ਰੋਕਾਂ ਦੀ ਵੀ ਜਾਂਚ ਕਰੋ। ਜੇ ਕੋਈ ਕਾਰਵਾਈ ਇੰਪਰਸੋਨੇਸ਼ਨ ਹੇਠ ਮਨਾਯਾ ਹੈ (ਪੂਰੇ ਭੁਗਤਾਨ ਵੇਰਵੇ ਵੇਖਣਾ, MFA ਬਦਲਣਾ, ਡਾਟਾ ਐਕਸਪੋਰਟ, ਪਾਸਵਰਡ ਰੀਸੈਟ), ਤਾਂ ਇਸਨੂੰ ਸਰਵਰ-ਸਾਈਡ ਤੇ ਰੋਕੋ, ਸਿਰਫ਼ UI 'ਤੇ ਨਹੀਂ। ਰੋਕੀ ਗਈ ਕੋਸ਼ਿਸ਼ ਦਾ ਤਰਕ ਸੀਧਾ ਦਿਖਾਓ ਅਤੇ ਉਸ ਦੀ ਲੌਗਿੰਗ ਕਰੋ।

ਜੇ ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਕਿਸ ਨੇ ਕੀ ਕੀਤਾ, ਕਿਸ ਉਪਭੋਗਤਾ ਨਾਲ, ਕਿਸ ਕਾਰਨ ਨਾਲ, ਅਤੇ ਕਿਸ ਮਨਜ਼ੂਰੀ ਹੇਠ, ਤਾਂ ਤੁਸੀਂ ਤਿਆਰ ਨਹੀਂ ਹੋ ਸ਼ਿਪ ਕਰਨ ਲਈ।

ਅਗਲੇ ਕਦਮ: ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਰੋਲਆਉਟ ਕਰੋ ਅਤੇ ਨਿਰੰਤਰ ਸੁਧਾਰ ਕਰੋ

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

ਪਾਇਲਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਕੁਝ ਅਨੁਭਵੀ ਸਪੋਰਟ ਏਜੰਟ ਚੁਣੋ, ਫਿਰ ਹਫ਼ਤੇ ਵਾਰੀ ਇੰਪਰਸੋਨੇਸ਼ਨ ਆਡਿਟ ਇਵੈਂਟਸ ਇਕੱਠੇ ਰਿਵਿਊ ਕਰੋ। ਪੈਟਰਨਾਂ ਨੂੰ ਵੇਖੋ: ਇੱਕੋ-ਏਕਸੈਂਟ ਖਾਤਿਆਂ ਲਈ ਦੁਹਰਾਈ ਗਈ ਪਹੁੰਚ, ਕਾਰਵਾਈਆਂ ਕਾਰੋਬਾਰੀ ਘੰਟਿਆਂ ਤੋਂ ਬਾਹਰ, ਜਾਂ ਐਸੀ ਕਾਰਵਾਈਆਂ ਜੋ ਟਿਕਟ ਹੱਲ ਕਰਨ ਲਈ ਲੋੜੀਂਦੀਆਂ ਨਹੀਂ ਸਨ।

ਰੋਲਆਉਟ ਯੋਜਨਾ ਸਧਾਰਣ ਰੱਖੋ: ਸਕੋਪ ਅਤੇ ਮਨਜ਼ੂਰੀ ਨਿਯਮ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ, 2-4 ਹਫ਼ਤੇ ਪਾਇਲਟ ਚਲਾਓ ਅਤੇ ਹਫ਼ਤੇਵਾਰ ਲੌਗ ਰਿਵਿਊ ਕਰੋ, ਮਨਾਏ ਗਏ ਕਾਰਵਾਈਆਂ ਲਈ ਟੈਸਟ ਕੇਸ ਸ਼ਾਮਿਲ ਕਰੋ ਅਤੇ ਜਾਂਚੋ ਕਿ ਸਰਵਰ ਉਨ੍ਹਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਘਟਨਾ ਜਵਾਬੀ ਮਾਲਕ ਨਿਰਧਾਰਤ ਕਰੋ, ਫਿਰ ਤਿਮਾਹੀ ਅਧਾਰ 'ਤੇ ਸਕੋਪਸ ਨੂੰ ਦੁਬਾਰਾ ਚੈੱਕ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਤੰਗ ਕਰੋ ਜੋ ਬਹੁਤ ਘੱਟ ਵਰਤੇ ਜਾ ਰਹੇ ਹਨ।

ਜੇ ਤੁਸੀਂ ਵਰਕਫਲੋ ਦਾ ਤੇਜ਼ ਪ੍ਰੋਟੋਟਾਈਪ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai (koder.ai) ਤੁਹਾਨੂੰ ਇੱਕ ਅੰਦਰੂਨੀ ਸਪੋਰਟ ਟੂਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣ ਅਤੇ ਗਾਰਡਰੇਲਾਂ ਨੂੰ ਅਸਲ ਟਿਕਟਾਂ ਨਾਲ ਟੈਸਟ ਕਰਨ ਵੇਲੇ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਵਰਤਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ।