07 ਦਸੰ 2025·8 ਮਿੰਟ
Claude Code ਲਈ ਸੰਵੇਦਨਸ਼ੀਲ ਸੰਦਰਭ ਘਟਾਉਣਾ — ਸੁਰੱਖਿਅਤ ਕੋਡਿੰਗ ਮਦਦ
ਪ੍ਰੈਕਟਿਕਲ ਪ੍ਰੋੰਪਟ ਟੈਂਪਲੇਟ, ਫਾਇਲ-ਸਾਂਝਾ ਵਰਕਫਲੋ ਅਤੇ ਰੈਡੈਕਸ਼ਨ ਕਦਮ ਸਿੱਖੋ ਤਾਂ ਜੋ Claude Code ਲਈ ਲੋੜੀਂਦਾ ਕੋਡਿੰਗ ਸਹਾਇਤਾ ਮਿਲੇ ਪਰ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਘੱਟ ਬਣਾਈ ਜਾਵੇ।
ਪ੍ਰੈਕਟਿਕਲ ਪ੍ਰੋੰਪਟ ਟੈਂਪਲੇਟ, ਫਾਇਲ-ਸਾਂਝਾ ਵਰਕਫਲੋ ਅਤੇ ਰੈਡੈਕਸ਼ਨ ਕਦਮ ਸਿੱਖੋ ਤਾਂ ਜੋ Claude Code ਲਈ ਲੋੜੀਂਦਾ ਕੋਡਿੰਗ ਸਹਾਇਤਾ ਮਿਲੇ ਪਰ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਘੱਟ ਬਣਾਈ ਜਾਵੇ।
“ਸੰਦਰਭ” ਓਹ ਸਭ ਕੁਝ ਹੈ ਜੋ ਤੁਸੀਂ ਮਾਡਲ ਨੂੰ ਦਿੰਦੇ ਹੋ: ਕੋਡ ਸਨਿੱਪੇਟ, ਸਟੈਕ ਟ੍ਰੇਸ, ਕਾਂਫਿਗ ਫਾਈਲਾਂ, ਐਨਵਾਇਰਨਮੈਂਟ ਵੈਰੀਏਬਲ, ਡੇਟਾਬੇਸ ਨਮੂਨੇ, ਸਕ੍ਰੀਨਸ਼ੌਟ ਅਤੇ ਉਸੇ ਚੈਟ ਦੇ ਪਹਿਲਾਂ ਵਾਲੇ ਸੁਨੇਹੇ। ਵੱਧ ਸੰਦਰਭ ਡੀਬੱਗਿੰਗ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਵੀ ਸੰਭਾਵਨਾ ਵਧਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੁਝ ਐਸਾ ਪੇਸਟ ਕਰ ਦੇਵੋਗੇ ਜੋ ਤੁਹਾਡੇ ਮਨੁੱਖੀ ਇਰਾਦੇ ਦੇ ਅਨੁਸਾਰ ਨਹੀਂ ਸੀ।
ਜ਼ਿਆਦਾ ਸ਼ੇਅਰ ਕਰਨ ਆਮ ਤੌਰ 'ਤੇ ਦਬਾਅ ਹੇਠਾਂ ਹੁੰਦਾ ਹੈ। ਕੋਈ ਬਗ ਰਿਲੀਜ਼ ਰੋਕ ਰਿਹਾ ਹੈ, ਡੈਮੋ ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ ਅਥ ਲੁੱਟ ਜਾਂਦੀ ਹੈ, ਜਾਂ CI ਵਿੱਚ flaky ਟੈਸਟ ਫੇਲ ਹੁੰਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਭਾਵਨਾਵਾਂ ਵਿੱਚ ਸੌਖਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਾਰਾ ਫਾਇਲ ਪੇਸਟ ਕਰ ਦਿਉ, ਫਿਰ ਸਾਰਾ ਲੌਗ, ਫਿਰ ਪੂਰਾ ਕਾਂਫਿਗ "ਸਦਕੇ"। ਟੀਮ ਆਦਤਾਂ ਵੀ ਇਹ ਹੀ ਦਿਸ਼ਾ ਚਲਾਉਂਦੀਆਂ ਹਨ: ਕੋਡ ਰਿਵਿਊ ਅਤੇ ਡੀਬੱਗਿੰਗ ਵਿੱਚ ਪੂਰੀ ਦਿੱਖ ਆਮ ਹੈ, ਭਾਵੇਂ ਕੇਵਲ ਇੱਕ ਛੋਟਾ ਹਿੱਸਾ ਲੋੜੀਂਦਾ ਹੋਵੇ।
ਖਤਰੇ ਕੱਲਪਨਾ ਨਹੀਂ ਹਨ। ਇਕ ਹੀ ਪੇਸਟ ਸਿਰਫ ਸੀਕਰੇਟ ਨਹੀਂ, ਗ੍ਰਾਹਕ ਡੇਟਾ ਜਾਂ ਅੰਦਰੂਨੀ ਸਿਸਟਮ ਵੇਰਵਾ ਵੀ ਲੀਕ ਕਰ ਸਕਦੀ ਹੈ। ਆਮ ਉਦਾਹਰਨਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਉਦੇਸ਼ ਗੁਪਤ ਰੱਖਣਾ ਨਹੀਂ ਹੈ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਉਹੋ ਸਭ ਤੋਂ ਘੱਟ ਹਿੱਸਾ ਸਾਂਝਾ ਕਰੋ ਜੋ ਸਮੱਸਿਆ ਨੂੰ ਦੁਹਰਾਉਂਦਾ ਜਾਂ ਫੈਸਲੇ ਨੂੰ ਸਮਝਾਉਂਦਾ ਹੈ, ਤਾਂ ਕਿ ਤੁਹਾਨੂੰ ਇਕੋ ਜਿਹੀ ਗੁਣਵੱਤਾ ਦੀ ਮਦਦ ਮਿਲੇ ਪਰ ਘੱਟ ਖੁਲਾਸਾ ਹੋਵੇ।
ਇੱਕ ਸਧਾਰਨ ਦਿਮਾਗੀ ਮਾਡਲ: ਸਹਾਇਕ ਨੂੰ ਇਕ ਬਾਹਰੀ ਸਹਿਯੋਗੀ ਵਜੋਂ ਸੋਚੋ ਜਿਸਨੂੰ ਤੁਹਾਡੀ ਪੂਰੀ ਰਿਪੋ ਦੀ ਲੋੜ ਨਹੀਂ। ਇੱਕ ਸਟੀਕ ਸਵਾਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ("ਇਹ ਬੇਨਤੀ 401 ਕਿਉਂ ਵਾਪਸ ਕਰਦੀ ਹੈ?")। ਫਿਰ ਸਿਰਫ ਉਹੋ ਦੇਵੋ ਜੋ ਉਸ ਸਵਾਲ ਨੂੰ ਸਹਾਰਦਾ ਹੈ: ਫੇਲ ਹੋਣ ਵਾਲੀ ਇਨਪੁਟ, ਉਮੀਦਿਤ ਆਊਟਪੁੱਟ, ਅਸਲ ਆਊਟਪੁੱਟ ਅਤੇ ਸੰਬੰਧਤ ਕੋਡ ਪਾਥ।
ਜੇ ਲੌਗਿਨ ਕਾਲ ਫੇਲ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ ਤੇ ਤੁਹਾਨੂੰ ਪੂਰਾ auth ਮੌਡਿਊਲ ਨਹੀਂ ਚਾਹੀਦਾ। ਇੱਕ ਸੈਨੀਟਾਈਜ਼ਡ request/response ਜੋੜਾ, ਹੈਡਰ ਬਣਾਉਣ ਵਾਲਾ ਫੰਕਸ਼ਨ ਅਤੇ ਸੰਬੰਧਤ ਕਾਂਫਿਗ ਚਾਬੀਆਂ (ਵੈਲਯੂਜ਼ ਬਦਲੇ ਹੋਏ) ਅਕਸਰ ਕਾਫੀ ਹੁੰਦੇ ਹਨ।
ਜਦੋਂ ਤੁਸੀਂ ਕੋਡ ਮਦਦ ਮੰਗਦੇ ਹੋ, “ਸੰਦਰਭ” ਸਿਰਫ ਸੋర్స్ ਕੋਡ ਨਹੀਂ ਹੈ। ਇਹ ਕੁਝ ਵੀ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਕਿਸੇ ਨੂੰ ਲੌਗਇਨ ਕਰਨ, ਕਿਸੇ ਵਿਅਕਤੀ ਦੀ ਪਛਾਣ ਕਰਨ ਜਾਂ ਤੁਹਾਡੇ ਸਿਸਟਮਾਂ ਦਾ ਨਕਸ਼ਾ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕੇ। ਪਹਿਲਾਂ ਇਹ ਜਾਣੋ ਕਿ ਕੀ toksic ਹੋ ਸਕਦਾ ਹੈ।
ਕ੍ਰੈਡੇਂਸ਼ੀਅਲ ਇੱਕ ਮਦਦਗਾਰ ਨਮੂਨੇ ਨੂੰ ਘਟਨਾ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ। ਇਸ ਵਿੱਚ API ਕੁੰਜੀਆਂ, ਟੋਕਨ, ਪ੍ਰਾਈਵੇਟ ਕੀਜ਼, ਸੈਸ਼ਨ ਕੁਕੀਜ਼, ਸਾਈਂਡ URLs, OAuth client secrets, ਡੇਟਾਬੇਸ ਪਾਸਵਰਡ ਅਤੇ ਲੌਗ ਵਿੱਚ ਛਾਪੇ ਗਏ "ਅਸਥਾਈ" ਟੋਕਨ ਸ਼ਾਮਲ ਹਨ।
ਅਕਸਰ ਅਚਾਨਕ Leak ਅਪਰੋਚ ਹੈ—ਤ੍ਰੁੱਟੀ ਸੁਨੇਹਾ ਪੂਰੇ request headers ਨਾਲ Authorization bearer token ਦਰਸਾ ਸਕਦਾ ਹੈ ਜਾਂ environment variable ਦਾ ਡੈਬੱਗ ਡੰਪ ਹੋ ਸਕਦਾ ਹੈ।
ਕੋਈ ਵੀ ਡੇਟਾ ਜੋ ਕਿਸੇ ਵਿਅਕਤੀ ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ ਸੰਵੇਦਨਸ਼ੀਲ ਹੋ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਦਿਖਣ ਵਿੱਚ ਸਧਾਰਣ ਲੱਗੇ। ਈਮੇਲ, ਨਾਂ, ਫੋਨ ਨੰਬਰ, ਪਤੇ, ਗਾਹਕ ID, ਕਰਮਚਾਰੀ ID, ਸਪੋਰਟ ਟਿਕਟ ਵਿਚਲੇ ਗੱਲਬਾਤ ਅਤੇ ਭੁਗਤਾਨ ਵੇਰਵੇ 'ਤੇ ਧਿਆਨ ਰੱਖੋ।
ਜੇ ਤੁਹਾਨੂੰ ਕੋਇ ਡੇਟਾ ਬੱਗ ਨੂੰ ਦੁਹਰਾਉਣ ਲਈ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਅਸਲੀ ਰਿਕਾਰਡਾਂ ਨੂੰ ਹਕੀਕਤੀ ਲੱਗਣ ਵਾਲੇ ਨਕਲੀ ਰਿਕਾਰਡ ਨਾਲ ਬਦਲੋ। ਡੇਟਾ ਦਾ ਰੂਪ (ਫੀਲਡ ਅਤੇ ਕਿਸਮ) ਰੱਖੋ, ਪਛਾਣ ਨਿਭਾਉਣ ਵਾਲੇ ਮੁੱਲ ਨਹੀਂ।
“ਰੁਟਿਨ” ਅੰਦਰੂਨੀ ਤੱਥ ਹੱਕੂਮਤਕਾਰਾਂ ਅਤੇ ਮੁਕਾਬਲੇ ਵਾਲਿਆਂ ਲਈ ਕੀਮਤੀ ਹੁੰਦੇ ਹਨ: ਹੋਸਟਨੇਮ, IPs, ਰੇਪੋ ਨਾਂ, ਟਿਕਟ IDs, ਵਿਕਰੇਤਾ ਨਾਂ, ਠੇਕੇ ਦੀਆਂ ਸ਼ਰਤਾਂ ਅਤੇ ਅੰਦਰੂਨੀ ਸਰਵਿਸ URL।
ਇੱਕ ਸਿੰਗਲ ਸਟੈਕ ਟ੍ਰੇਸ ਵੀ ਫੋਲਡਰ ਪਾਥ, ਯੂਜ਼ਰਨੇਮ ਜਾਂ ਕਲਾਇੰਟ ਨਾਂ, ਸਰਵਿਸ ਨੇਮਿੰਗ ਰੀਤੀ ਅਤੇ ਕਲਾਉਡ ਖਾਤੇ ਦੀਆਂ ਸੰਕੇਤਕ ਜਾਣਕਾਰੀਆਂ ਦਰਸਾ ਸਕਦਾ ਹੈ।
ਸਾਰੇ ਕੋਡ ਇੱਕੋ ਜਿਹਾ ਨਾਹ ਹੁੰਦਾ। ਸਭ ਤੋਂ ਖਤਰਨਾਕ ਹਿੱਸੇ ਉਹੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਵਪਾਰ ਦੇ ਤਰੀਕੇ ਨੂੰ ਡੇਫਾਈਨ ਕਰਦੇ ਹਨ: ਪ੍ਰਾਈਸਿੰਗ ਨਿਯਮ, ਫਰੌਡ ਚੈਕ, ਰਿਕਮੈਂਡੇਸ਼ਨ ਲਾਜਿਕ, LLM ਲਈ ਪ੍ਰੌਂਪਟ ਟੈਂਪਲੇਟ ਅਤੇ ਰਣਨੀਤੀ ਦਸਤਾਵੇਜ਼।
ਜੇ ਤੁਹਾਨੂੰ ਬੱਗ ਵਿੱਚ ਮਦਦ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਉਹੋ ਸਭ ਤੋਂ ਛੋਟਾ ਫੰਕਸ਼ਨ ਸਾਂਝਾ ਕਰੋ ਜੋ ਇਸ ਨੂੰ ਦੁਹਰਾਉਂਦਾ ਹੈ, ਪੂਰਾ ਮੌਡਿਊਲ ਨਹੀਂ।
ਸੰਵੇਦਨਸ਼ੀਲ ਵੇਰਵਾ ਅਕਸਰ ਅਜਿਹੇ ਥਾਵਾਂ ਵਿੱਚ ਛੁਪਾ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਧਿਆਨ ਨਹੀਂ ਦਿੰਦੇ: ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਨਾਂ, commit ਸੁਨੇਹੇ, TODOs ਜੋ ਗਾਹਕਾਂ ਦਾ ਹਵਾਲਾ ਦਿੰਦੇ ਹਨ ਅਤੇ ਸਟੈਕ ਟ੍ਰੇਸ ਜੋ “ਜਿਵੇਂ-ਹੇ” ਪੇਸਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਕਾਂਫਿਗ ਫਾਈਲਾਂ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਖਤਰਨਾਕ ਹਨ ਕਿਉਂਕਿ ਉਹ ਸਧਾਰਣ ਸੈਟਿੰਗਜ਼ ਨਾਲ ਸੀਕ੍ਰੇਟ ਮਿਲਾ ਦਿੰਦੀਆਂ ਹਨ।
ਇੱਕ ਪ੍ਰਯੋਗਤ ਨਿਯਮ: ਜੇ ਲਿਖਤ ਕਿਸੇ ਬਾਹਰੀ ਨਮੂਨੇ ਤੇਜ਼ੀ ਨਾਲ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ ਔਰਾਹਲ ਇੱਕ clean-room ਉਦਾਹਰਨ ਉਸੇ ਤਰ੍ਹਾਂ ਨਹੀਂ ਕਰ ਸਕਦੀ, ਤਾਂ ਉਸਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲ ਮੰਨੋ ਅਤੇ ਰੈਡੈਕਟ ਜਾਂ ਬਦਲੋ।
ਸਬ ਤੋਂ ਵਧੀਆ ਸਮਾਂ ਤੁਹਾਡੀ ਐਡੀਟਰ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਹੋਰ ਖਰਚ ਘਟਾਉਣਾ ਹੈ। 30 ਸਕਿੰਟ ਦੀ ਰੁਕਾਵਟ ਆਪਣੇ ਨਤੀਜੇ ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕਰ ਲੈਂਦੀ ਹੈ ਅਤੇ ਅਕਸਰ ਇਹ ਸਭ ਤੋਂ ਵੱਧ ਹਿੱਸਾ ਕੱਟ ਦਿੰਦੀ ਹੈ।
ਪਹਿਲਾਂ ਨਤੀਜੇ ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਨਾਮ ਦਿਓ। ਕੀ ਤੁਸੀਂ ਬੱਗ ਦਾ ਕਾਰਨ ਲੱਭਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਸੁਰੱਖਿਅਤ refactor ਦੀ ਯੋਜਨਾ ਬਣਾਉਣੀ ਹੈ, ਜਾਂ ਟੈਸਟ ਡਿਜ਼ਾਈਨ ਕਰਨੇ ਹਨ? ਹਰ ਇੱਕ ਟੀਚੇ ਲਈ ਵੱਖ-ਵੱਖ ਇਨਪੁਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਬੱਗ ਹੰਟਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਟੈਕ ਟ੍ਰੇਸ ਅਤੇ ਇੱਕ ਛੋਟੀ ਫੰਕਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। Refactor ਸਵਾਲਾਂ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ public interfaces ਅਤੇ ਵਰਤੋਂ ਦੇ ਛੋਟੇ ਉਦਾਹਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਫਿਰ ਇੱਕ “ਨਿਊਨਤਮ ਆਰਟੀਫੈਕਟ” ਚੁਣੋ ਜੋ ਸਮੱਸਿਆ ਨੂੰ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਉਹੋ ਸਭ ਤੋਂ ਛੋਟਾ ਚੀਜ਼ ਚੁਣੋ ਜੋ ਫੇਲ ਹੁੰਦਾ ਹੈ: ਇੱਕ failing test, ਸਭ ਤੋਂ ਛੋਟਾ snippet ਜੋ error trigger ਕਰਦਾ ਹੈ, ਫੇਲ ਵੇਲੇ ਦਾ ਛੋਟਾ ਲੌਗ ਅੰਸ਼, ਜਾਂ placeholder ਵਾਲਾ ਸਧਾਰਣ ਕਾਂਫਿਗ ਉਦਾਹਰਨ।
ਜਦੋਂ ਤੁਸੀਂ ਡੇਟਾ ਦਾ ਵਰਣਨ ਕਰੋ, ਤਾਂ ਮੁੱਲਾਂ ਦੀ ਥਾਂ shape ਨੂੰ ਤਰਜੀਹ ਦਿਓ। “User object has id (UUID), email (string), role (enum), createdAt (timestamp)” ਆਮ ਤੌਰ 'ਤੇ ਕਾਫੀ ਹੁੰਦਾ ਹੈ। ਜੇ ਉਦਾਹਰਨਾਂ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਨਕਲੀ ਪਰ ਜੋ ਰੂਪ ਤੇ ਖਾਸਤੌਰ 'ਤੇ ਮਿਲਦੇ-ਜੁਲਦੇ ਹੋਣ ਵਾਲੇ ਮੁੱਲ ਵਰਤੋ, ਅਸਲੀ ਰਿਕਾਰਡ ਨਹੀਂ।
ਫਾਇਲਾਂ ਬਾਰੇ ਕਟੋਰ ਰਹੋ। ਕੇਵਲ ਉਹੋ ਮੌਡੀਊਲ ਸਾਂਝਾ ਕਰੋ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਤਬਦੀਲੀਆਂ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਉਨ੍ਹਾਂ ਇੰਟਰਫੇਸਾਂ ਨੂੰ ਜੋ ਇਹ ਛੂਹਦਾ ਹੈ। ਜੇ ਇੱਕ ਫੰਕਸ਼ਨ ਹੋਰ ਮੌਡੀਊਲ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਅਕਸਰ ਤੁਹਾਨੂੰ ਸਿਰਫ ਸਿਗਨੇਚਰ ਅਤੇ ਉਸ ਦੇ ਵਾਪਸੀ ਦੀ ਛੋਟੀ ਵਰਣਨਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇ ਇੱਕ ਬੱਗ ਨਾਲ ਹੋਰ ਸਰਵਿਸ ਨੂੰ ਰਿਕਵੇਸਟ ਕਰਨੀ ਪੈਂਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ request shape, ਹੈਡਰ ਨਾਂ (ਵੈਲਯੂ ਨਹੀਂ), ਅਤੇ ਉਮੀਦਤ response shape ਦੀ ਲੋੜ ਰੱਖਦੇ ਹੋ।
ਇਹ ਹਾਰਡ ਬਾਊਂਡਰੀ ਹਮੇਸ਼ਾ ਆਪਣੀ ਮਸ਼ੀਨ 'ਤੇ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਨੇ: API ਕੁੰਜੀਆਂ, ਪ੍ਰਾਈਵੇਟ ਸਰਟੀਫਿਕੇਟ, ਐਕਸੈਸ ਟੋਕਨ, ਗਾਹਕ ਡੇਟਾ, ਅੰਦਰੂਨੀ URLs, ਪੂਰੇ ਰਿਪੋ ਡੰਪ ਅਤੇ ਕੱਚੇ ਪ੍ਰੋਡਕਸ਼ਨ ਲੌਗ। ਜੇ ਤੁਸੀਂ 401 ਡੀਬੱਗ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ auth flow ਅਤੇ error message ਸਾਂਝਾ ਕਰੋ, ਪਰ ਟੋਕਨ ਨੂੰ TOKEN_REDACTED ਅਤੇ ਈਮੇਲ ਨੂੰ [email protected] ਨਾਲ ਬਦਲੋ।
ਚੰਗੀ ਰੈਡੈਕਸ਼ਨ ਸਿਰਫ ਸੀਕ੍ਰੇਟ ਲੁਕਾਉਣ ਨਹੀਂ ਹੈ। ਇਹ ਸਮੱਸਿਆ ਦੀ ਰਚਨਾ ਠੀਕ ਰੱਖਦੀ ਹੈ ਤਾਂ ਕਿ ਸਹਾਇਕ ਅਜੇ ਵੀ ਤਰਕ ਕਰ ਸਕੇ। ਜਿਆਦਾ ਹਟਾਉਣ ਨਾਲ ਤੁਸੀਂ ਜਨਰਿਕ ਸਲਾਹ ਪਾਵੋਗੇ। ਬਹੁਤ ਘੱਟ ਹਟਾਉਣ ਨਾਲ ਡੇਟਾ ਲੀਕ ਹੋ ਸਕਦੀ ਹੈ।
ਇੱਕ placeholder ਸ਼ੈਲੀ ਚੁਣੋ ਅਤੇ ਕੋਡ, ਕਾਂਫਿਗ ਅਤੇ ਲੌਗ 'ਚ ਉਸਤੋਂ ਸਟਿਕ ਰਹੋ। ਇੱਕੋ TOKEN ਜੇ ਤਿੰਨ ਥਾਂ ਤੇ ਆਇਆ ਹੈ ਤਾਂ ਉਸਨੂੰ ਤਿੰਨ ਵੱਖਰੇ ਤਰੀਕਿਆਂ ਨਾਲ ਨਾ ਬਦਲੋਂ। ਵਰਤੋਂ: API_KEY_1, TOKEN_1, USER_ID_1, CUSTOMER_ID_1, EMAIL_1 ਅਤੇ ਲੋੜ ਅਨੁਸਾਰ ਇੰਕਰੀਮੈਂਟ ਕਰੋ (TOKEN_2, TOKEN_3)।
ਛੋਟਾ legend ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ:
TOKEN_1: Authorization header ਵਿੱਚ ਵਰਤਿਆ ਗਿਆ bearer tokenCUSTOMER_ID_1: ਡੇਟਾਬੇਸ ਲੁੱਕਅਪ ਵਿੱਚ ਵਰਤਿਆ ਅੰਦਰੂਨੀ ਗਾਹਕ identifierਕੁਝ ਬੱਗ ਲੰਬਾਈ ਅਤੇ ਢਾਂਚੇ ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ (parsing, validation, signature checks, regex)। ਉਹਨਾਂ ਕੇਸਾਂ ਵਿੱਚ, ਵਿਲੱਖਣ strings ਨੂੰ ਅਜਿਹੇ ਡਮੀ ਮੁੱਲ ਨਾਲ ਬਦਲੋ ਜੋ ਰੂਪ ਵਿੱਚ ਮਿਲਦੇ-ਜੁਲਦੇ ਹਨ।
ਉਦਾਹਰਨ:
ਇਸ ਨਾਲ ਤੁਸੀਂ ਕਹਿ ਸਕਦੇ ਹੋ “ਟੋਕਨ validation fail ਕਰ ਰਿਹਾ ਹੈ” ਬਿਨਾਂ ਅਸਲੀ ਟੋਕਨ ਨੂੰ ਦਰਸਾਉਂਦੇ।
JSON ਸਾਂਝਾ ਕਰਦਿਆਂ, ਕੀਜ਼ ਨੂੰ ਰੱਖੋ ਅਤੇ ਮੁੱਲ ਬਦਲੋ। ਕੀਆ ਸਿਸਟਮ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ; ਮੁੱਲ ਅਕਸਰ ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦੇ ਹਨ।
ਬਜਾਏ:
{"email":"[email protected]","password":"SuperSecret!","mfa_code":"123456","customer_id":"c8b1..."}
ਇਸਨੂੰ ਸਾਂਝਾ ਕਰੋ:
{"email":"EMAIL_1","password":"PASSWORD_1","mfa_code":"MFA_CODE_1","customer_id":"CUSTOMER_ID_1"}
SQL ਲਈ ਵੀ ਇੱਕੋ ਵਿਚਾਰ: ਟੇਬਲ ਨਾਂ, joins ਅਤੇ conditions ਰੱਖੋ, ਪਰ literals ਹਟਾਓ।
WHERE user_id = USER_ID_1 AND created_at > DATE_1ਜੇ ਇਕ ਫੰਕਸ਼ਨ ਵਿੱਚ ਵਪਾਰਕ ਨੀਤੀਆਂ ਜਾਂ proprietary logic ਹੈ, ਤਾਂ ਉਸਨੂੰ ਵਰਣਨ ਕਰੋ। ਜੋ ਕੁਝ ਬੱਗ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾ ਰਿਹਾ ਹੈ ਉਹ ਰੱਖੋ: ਇਨਪੁਟ, ਆਉਟਪੁੱਟ, ਸਾਈਡ-ਇਫੈਕਟ ਅਤੇ error handling।
ਉਦਾਹਰਨ ਸੰਖੇਪ:
“signRequest(payload) ਇੱਕ JSON payload ਲੈਂਦਾ ਹੈ, timestamp ਅਤੇ nonce ਜੋੜਦਾ ਹੈ, ਫਿਰ method + path + body ਤੋਂ HMAC SHA-256 signature ਬਣਾਉਂਦਾ ਹੈ। ਇਹ {headers, body} ਵਾਪਸ ਕਰਦਾ ਹੈ। error ਉਸ ਵਕਤ ਹੁੰਦੀ ਹੈ ਜਦ payload ਵਿੱਚ non-ASCII ਅੱਖਰ ਸ਼ਾਮਿਲ ਹੋਣ।”
ਇਹ ਆਮ ਤੌਰ 'ਤੇ encoding, canonicalization ਅਤੇ signature mismatches ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਕਾਫੀ ਹੁੰਦਾ ਹੈ ਬਿਨਾਂ ਪੂਰਾ implementation ਸਾਂਝਾ ਕੀਤੇ।
ਆਪਣੇ ਪ੍ਰੋੰਪਟ ਦੇ ਅੰਤ ਵਿੱਚ ਦੱਸੀਓ ਕਿ ਤੁਸੀਂ ਕੀ ਹਟਾਇਆ ਅਤੇ ਕੀ ਰੱਖਿਆ। ਇਹ ਬੈਕ-ਅੰਦ-ਫੋਰਥ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਸੰਭਾਵਨਾ ਘਟਾਉਂਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਹੋਰ ਪੇਸਟ ਕਰਨ ਲਈ ਬੇਨਤੀ ਕੀਤੀ ਜਾਵੇ।
ਉਦਾਹਰਨ:
“Redacted: tokens, emails, customer data, full request bodies. Kept: endpoint paths, status codes, header names, stack trace frames, and the exact error text.”
ਸਹਾਇਕ ਨੂੰ ਇਕ ਸਹਿਯੋਗੀ ਸਮਝੋ ਜਿਸਨੂੰ ਸਿਰਫ ਉਹੋ ਚੀਜ਼ ਚਾਹੀਦੀ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਕੰਮ ਕਰ ਰਹੇ ਹੋ। ਪੂਰੇ ਫਾਇਲਾਂ ਦੀ ਥਾਂ ਇੰਟਰਫੇਸ ਅਤੇ ਕਾਂਟਰੈਕਟ ਸਾਂਝਾ ਕਰੋ: ਫੰਕਸ਼ਨ ਸਿਗਨੇਚਰ, ਕਿਸਮਾਂ, request/response shapes ਅਤੇ ਸਹੀ error ਟੈਕਸਟ।
ਸਧਾਰਨ ਰਿਪ੍ਰੋ ਉਪਾਅਕਦੀਆਂ ਬਹੁਤ ਵਾਰ ਕਾਫੀ ਹੁੰਦੀਆਂ ਹਨ: ਤੁਸੀਂ ਵਰਤੇ ਇਨਪੁਟ, ਉਮੀਦ ਕੀਤੀ ਚੀਜ਼, ਹੋਈ ਚੀਜ਼ ਅਤੇ ਕੁਝ ਵਾਤਾਵਰਣ ਨੋਟ (ਰੰਨਟਾਈਮ ਵਰਜਨ, OS, ਫਰੇਮਵਰਕ) ਦਿਓ। ਤੁਹਾਨੂੰ ਪੂਰੇ ਪ੍ਰੋਜੈਕਟ ਇਤਿਹਾਸ ਦੀ ਲੋੜ ਨਹੀਂ।
ਕੁਝ ਟੈਂਪਲੇਟ ਜੋ ਅਚ্ছে ਕੰਮ ਕਰਦੇ ਹਨ:
ਇਕ ਸੈਨਟਾਈਜ਼ਡ ਕਾਂਫਿਗ ਬਲਾਕ ਇੱਕ ਚੰਗਾ ਮਧਯਮ ਹੈ। ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਨੋਬਜ਼ ਹਨ ਬਿਨਾਂ ਸੀਕ੍ਰੇਟ ਖੋਲ੍ਹੇ:
# sanitized
DB_HOST: "<set>"
DB_PORT: "5432"
DB_USER: "<set>"
DB_PASSWORD: "<redacted>"
JWT_SECRET: "<redacted>"
OAUTH_CLIENT_ID: "<set>"
OAUTH_CLIENT_SECRET: "<redacted>"
ਸੁਰੱਖਿਅਤ ਪ੍ਰੋੰਪਟ ਉਦਾਹਰਨ:
“Login fails with 401. Expected 200. Actual response body: ‘invalid token’. Environment: Node 20, local dev, time sync enabled. Request contract: Authorization: Bearer <redacted>. Verify steps: token is issued by /auth/login and used on /me. What are the top causes (clock skew, audience mismatch, signing secret mismatch), and what single check confirms each?”
ਇੱਕ ਭਰੋਸੇਯੋਗ ਆਦਤ ਇਹ ਹੈ ਕਿ ਸਾਂਝਾ ਕਰਨਾ ਇਕ ਛੋਟਾ reproduction ਪੈਕੇਜ ਕਰਨਾ ਸਮਝੋ। ਬਿਲਕੁਲ ਜਿੰਨਾ ਚਾਹੀਦਾ ਹੈ ਉਹੀ ਸਾਂਝਾ ਕਰੋ, ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ।
ਇੱਕ ਪ੍ਰਯੋਗਤ ਤਰੀਕਾ ਇੱਕ ਅਸਥਾਈ “share folder” ਬਣਾਉਣਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਅਸਲ ਰਿਪੋ ਤੋਂ ਵੱਖਰਾ ਹੋਵੇ। ਫਾਇਲਾਂ ਨੂੰ ਮੈਨੁਅਲ ਤੌਰ 'ਤੇ ਉਸ ਵਿੱਚ ਕਾਪੀ ਕਰੋ ਨਾ ਕਿ ਆਪਣੇ ਪੂਰੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਸ਼ੇਅਰ ਕਰੋ। ਇਸ ਨਾਲ ਇਰਾਦਾਨਾ ਚੋਣਾਂ ਕਰਨੀ ਮਜ਼ਬੂਰਕੀ ਬਣਦੀ ਹੈ।
Workflow ਸਧਾਰਣ ਰੱਖੋ:
ਫੋਲਡਰ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਬਾਹਰੀ ਵ੍ਯਕਤੀ ਵਾਂਗੌ ਪੜ੍ਹੋ। ਜੇ ਕੋਈ ਫਾਇਲ ਨਿਰਧਾਰਤ ਸਮੱਸਿਆ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਦੀ, ਤਾਂ ਉਹ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।
ਜਦੋਂ ਤੁਸੀਂ ਰੈਡੈਕਟ ਕਰਦੇ ਹੋ, ਕੋਡ ਜਾਂ ਲੌਗ ਨੂੰ ਤੋੜੋ ਨਹੀਂ। ਮੁੱਲਾਂ ਨੂੰ ਉਹਨਾਂ ਦੀ ਕਿਸਮ ਅਤੇ ਸਿਰੰਜਚਾ ਨੂੰ ਬਚਾਉਂਦੇ ਹੋਏ ਅਸਾਨ placeholders ਨਾਲ ਬਦਲੋ। ਉਦਾਹਰਨ ਦੇ ਲਈ:
DATABASE_URL=postgres://user:[email protected]:5432/app
ਨਾਲ ਬਦਲੋ:
DATABASE_URL=postgres://user:REDACTED@localhost:5432/app
ਜੇ ਬੱਗ ਕਿਸੇ ਤੀਸਰੇ-ਪਾਰਟੀ ਦੇ ਜਵਾਬ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ README ਵਿੱਚ response shape ਲਿਖੋ ਅਤੇ ਇਕ ਸਿੰਥੇਟਿਕ JSON ਫਾਇਲ ਸ਼ਾਮਿਲ ਕਰੋ ਜੋ ਉਸਨੂੰ ਮਿਲਦਾ-ਜੁਲਦਾ ਹੋਵੇ। ਇਸ ਤਰ੍ਹਾਂ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਸਾਂਝਾ ਕੀਤੇ ਬਿਨਾਂ ਵੀ ਮਾਨਯੋਗ ਡੀਬੱਗਿੰਗ ਮਿਲ ਸਕਦੀ ਹੈ।
ਇੱਕ ਦੁਹਰਾਊ ਲੂਪ ਵਰਤੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਦਬਾਅ ਹੇਠਾਂ improvisation ਨਾ ਕਰੋ।
ਪਹਿਲਾਂ ਦੋ ਵਾਕ ਲਿਖੋ।
ਨਿਊਨਤਮ ਇਨਪੁਟ ਇਕੱਠੇ ਕਰੋ। ਸਿਰਫ ਉਹੀ ਲੈ ਆਓ ਜੋ ਦੁਹਰਾਉਣ ਜਾਂ ਵਿਚਾਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ: ਫੇਲ ਹੋਣ ਵਾਲੇ ਲਾਈਨ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਛੋਟਾ snippet, ਸਹੀ error ਟੈਕਸਟ, ਸੰਬੰਧਤ ਵਰਜਨ ਅਤੇ 3-5 repro ਕਦਮ।
ਢਾਂਚਾ ਠੀਕ ਰੱਖਦੇ ਹੋਏ ਰੈਡੈਕਟ ਕਰੋ। ਸੀਕ੍ਰੇਟ ਨੂੰ placeholders ਨਾਲ ਬਦਲੋ ਅਤੇ ਉਹਨਾਂ ਪਢਾਂਚਿਆਂ ਨੂੰ ਰੱਖੋ। ਉਨ੍ਹਾਂ ਪਢਾਂਚਿਆਂ ਜੋ ਵਿਹਾਰ 'ਤੇ ਪ੍ਰਭਾਵ ਨਹੀਂ ਪਾ ਰਹੀਆਂ ਉਹਨਾਂ ਨੂੰ ਹਟਾਓ (ਪ੍ਰੋਜੈਕਟ ਨਾਂ, tenant IDs, ਈਮੇਲ)। placeholders ਸਥਿਰ ਰੱਖੋ।
API_KEY=sk_live_...
becomes
API_KEY=<API_KEY>
customer-1234-prod-db
becomes
<DB_HOST_PROD>
ਲਕੜੇ ਸਵਾਲ ਪੁੱਛੋ। “ਸਭ ਤੋਂ ਸੰਭਾਵਿਤ ਕਾਰਨ ਕੀ ਹੈ?” ਦੇ ਨਾਲ “ਮੈਂ ਕੀ ਬਦਲਾਂ?” ਜੋੜੋ। ਜੇ ਤੁਸੀਂ patch ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਕਿਸ਼ਤੀ ਨੂੰ ਲਿਮਟ ਕਰੋ ਅਤੇ ਮੰਨਿਆ ਜਾਵੇ ਇਹ ਮੰਨਤੀਆਂ ਲੇਬਲ ਹੋਣ।
ਲੋਕਲ ਤੌਰ 'ਤੇ ਵੇਰਿਫਾਈ ਕਰੋ, ਫਿਰ ਇੱਕ ਨਵਾਂ ਵੇਰਵਾ ਜੋੜੋ। ਸੁਝਾਅ ਨੂੰ ਟੈਸਟ ਕਰੋ। ਜੇ ਇਹ ਫੇਲ ਹੋਵੇ, ਤਾਂ ਸਿਰਫ਼ ਇੱਕ ਨਵੀਂ ਜਾਣਕਾਰੀ (ਅਗਲਾ ਸਟੈਕ ਟ੍ਰੇਸ ਲਾਈਨ, ਇਕ config ਫਲੈਗ, ਇਕ ਨੈਰੋਰੇਪ੍ਰੋ) ਜੋੜੋ। ਸਿੱਧੇ ਹੀ ਪੂਰਾ ਫਾਇਲ ਪੇਸਟ ਕਰਨ ਤੇ ਛਾਲ ਮਾਰੋ ਨਾ।
ਇਹ ਧੀਰੇ-ਧੀਰੇ ਖੁਲਾਸਾ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਅਸਲੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਸੀਕ੍ਰੇਟ ਅਤੇ ਗੈਰ-ਸੰਬੰਧਿਤ ਕੋਡ prompts ਤੋਂ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ।
ਆਮ ਸਥਿਤੀ: ਲੌਗਿਨ ਤੁਹਾਡੇ ਲੈਪਟੌਪ ਅਤੇ ਸਟੇਜਿੰਗ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਫੇਲ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਮਦਦ ਚਾਹੀਦੀ ਹੈ, ਪਰ ਤੁਸੀਂ ਅਸਲੀ ਟੋਕਨ, ਯੂਜ਼ਰ ਈਮੇਲ, ਅੰਦਰੂਨੀ ਹੋਸਟਨੇਮ ਜਾਂ ਪੂਰਾ auth middleware ਪੇਸਟ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਉਹ ਸਾਂਝਾ ਕਰੋ: request ਅਤੇ response shape, ਸਥਿਤੀ ਕੋਡ ਅਤੇ ਇੱਕ ਛੋਟਾ ਸਟੈਕ ਟ੍ਰੇਸ। ਜੇ JWT-ਸਬੰਧੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਨਾ-ਸੰਵੇਦਨਸ਼ੀਲ ਹੈਡਰ ਵੇਰਵੇ (ਜਿਵੇਂ ਉਮੀਦਿਤ algorithm) ਅਤੇ ਸਮੇਂ ਦੇ ਅੰਸ਼ (ਸਰਵਰ ਟਾਈਮ ਡ੍ਰਿਫਟ) ਵੀ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹੋ। ਹੋਰ ਕੁਝ ਵੀ placeholder ਵਿੱਚ ਬਦਲ ਦਿਓ।
ਇੱਕ ਸੁਰੱਖਿਅਤ ਬੰਡਲ ਅਕਸਰ ਸ਼ਾਮਿਲ ਹੁੰਦਾ ਹੈ:
ਫਿਰ ਇੱਕ ਫੋਕਸਡ ਸਵਾਲ ਪੁੱਛੋ। ਪ੍ਰੋਡਕਸ਼ਨ-ਕੇਵਲ auth ਫੇਲ ਆਮ ਤੌਰ 'ਤੇ clock skew, ਗਲਤ issuer/audience, ਵੱਖ-ਵੱਖ signing keys, key rotation ਦੀ ਕਮੀ ਜਾਂ proxy/header ਫਰਕ ਤੋਂ ਹੁੰਦੇ ਹਨ।
ਪ੍ਰੋੰਪਟ ਨਮੂਨਾ:
I have a production-only login/auth failure. Locally it passes.
Observed behavior:
- Endpoint: POST /api/login
- Production response: 401 with message "invalid token" (generic)
- Staging/local: 200
Sanitized request/response:
- Authorization: Bearer <JWT_REDACTED>
- Expected claims: iss=<ISSUER_PLACEHOLDER>, aud=<AUDIENCE_PLACEHOLDER>
- Token validation library: <LIB_NAME_AND_VERSION>
Sanitized log snippet:
<PASTE 5-10 LINES WITH TOKENS/EMAILS/HOSTS REDACTED>
Question:
Given this, what are the top causes of JWT validation failing only in production, especially clock skew or claim mismatch? What specific checks and log lines should I add to confirm which one it is?
ਹੈਪਸਥਿਤੀਆਂ ਤੋਂ ਬਾਅਦ, ਘੱਟ-ਸੰਵੇਦਨ facts (exp, iat, now, failure 이유 ਕੋਡ) ਪ੍ਰਿੰਟ ਕਰਨ ਵਾਲਾ ਅਸਥਾਈ ਲੋਿਗਿੰਗ ਜੋੜੋ। ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਲਿਖੋ ਜੋ ਇੱਕ ਜਾਣਿਆ-ਪਹੁੰਚ ਟੋਕਨ ਫਿਕਸਚਰ ਨੂੰ ਫੀਡ ਕਰਦਾ ਹੈ ਅਤੇ validator ਵਿਹਾਰ ਲਈ assertions ਕਰਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਯੋਜਨਾ:
ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਪ੍ਰਾਈਵੇਸੀ ਦੇ ਫਾਇਦੇ ਗੁਆਉਣ ਦੀ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ “ਇਕ ਛੋਟੀ ਚੀਜ਼” ਪੇਸਟ ਕਰੋ ਜੋ ਆਹਿਸਤਾ-ਆਹਿਸਤਾ ਸਭ ਕੁਝ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ। ਪੂਰਾ .env ਜਾਂ ਕਾਂਫਿਗ ਫਾਈਲ ਪੇਸਟ ਕਰਨਾ ਕਲਾਸਿਕ ਉਦਾਹਰਨ ਹੈ। ਭਾਵੇਂ ਤੁਸੀਂ ਵਿਖੇ ਰਹੇ ਸੀਕ੍ਰੇਟ ਹਟਾ ਦਿਓ, ਉਹ ਫਾਈਲ ਆਮ ਤੌਰ 'ਤੇ ਅੰਦਰੂਨੀ ਹੋਸਟਨੇਮ, ਸਰਵਿਸ ਨਾਂ ਅਤੇ ਵਾਤਾਵਰਣ ਸੰਕੇਤ ਸ਼ਾਮਿਲ ਕਰ ਲੈਂਦੀ ਹੈ ਜੋ ਤੁਹਾਡੇ ਸਿਸਟਮ ਦਾ ਨਕਸ਼ਾ ਬਣਾਉਂਦੇ ਹਨ।
ਪੂਰੇ ਸਟੈਕ ਟ੍ਰੇਸ ਇਕ ਹੋਰ ਆਮ ਲੀਕ ਰਾਹ ਹੈ। ਉਹ ਯੂਜ਼ਰਨੇਮ, ਮਸ਼ੀਨ ਨਾਂ, ਰੇਪੋ ਨਾਂ, ਅਤੇ ਅਬਸੋਲਿਊਟ ਪਾਥਾਂ ਜਿਵੇਂ /Users/alex/company-payments/... ਸ਼ਾਮਿਲ ਕਰ ਸਕਦੇ ਹਨ। ਕਈ ਵਾਰ ਉਹ HTTP query strings, headers ਜਾਂ error objects ਨਾਲ ਟੋਕਨ ਵੀ ਰੱਖਦੇ ਹਨ। ਜੇ ਤੁਹਾਨੂੰ ਟ੍ਰੇਸ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਸਿਰਫ ਸਬੰਧਤ ਫਰੇਮ ਕਾਪੀ ਕਰੋ ਅਤੇ ਪਾਥ placeholder ਨਾਲ ਬਦਲੋ।
ਅਸਲੀ ਗਾਹਕ ਪੇਲੋਡ ਵੀ ਖਤਰਨਾਕ ਹੁੰਦੇ ਹਨ ਭਾਵੇਂ ਉਹ "ਛੋਟੇ" ਲੱਗਣ। ਇਕ JSON ਬਾਡੀ ਵਿੱਚ ਈਮੇਲ, ਪਤੇ, ਆਰਡਰ IDs ਜਾਂ ਮੁਕਤ-ਟੈਕਸਟ ਨੋਟਸ ਹੋ ਸਕਦੇ ਹਨ। ਸੁਰੱਖਿਅਤ ਚੋਣ ਹੈ ਇੱਕ ਨਕਲੀ ਪੇਲੋਡ ਬਣਾਉਣਾ ਜੋ ਰੂਪ ਅਤੇ ਕੌਨਰ-ਕੇਸਾਂ ਨੂੰ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ (missing fields, ਲੰਬੇ strings, ਅਜੀਬ ਅੱਖਰ) ਬਿਨਾਂ ਅਸਲੀ ਮੁੱਲਾਂ ਦੇ।
ਅਸੰਗਤ placeholders ਵੀ ਮੁਸ਼ਕਲ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਜੇ USER_ID ਇਕ ਥਾਂ ਤੇ “customer id” ਅਤੇ ਦੂਜੀ ਥਾਂ ਤੇ “internal account id” ਦੇ ਲਈ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਗਲਤ ਨਿ:ਸ਼ਚ ਮਿਲੇਗਾ। ਇਕ ਯੋਜਨਾ ਚੁਣੋ ਅਤੇ ਉਸਦੇ ਨਾਲ ਰਹੋ।
ਜੇ ਤੁਹਾਡਾ ਸੁਨੇਹਾ ਕਿਸੇ ਅਜਿਹੇ ਵਿਅਕਤੀ ਨੂੰ ਲੌਗਿਨ ਕਰਨ, ਸਰਵਰਾਂ ਦੀ ਸਥਿਤੀ ਪਛਾਣ ਕਰਨ ਜਾਂ ਗਾਹਕ ਪਛਾਣਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ ਤਾਂ ਇਹ ਹੋਰ ਇੱਕ ਪਾਸ ਦੌਰਾ ਲੋੜਦੀ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਧਿਆਨ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੇਜ਼ੀ ਤੁਹਾਡਾ ਦੁਸ਼ਮਣ ਹੁੰਦੀ ਹੈ। ਇਕ ਛੋਟੀ ਰੂਟੀਨ ਤੁਹਾਨੂੰ ਸਹੀ ਜਵਾਬ ਦੇ ਸਕਦੀ ਹੈ ਬਿਨਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਦੇ।
ਸੀਕ੍ਰੇਟਸ ਲਈ ਇੱਕ ਪਾਸ ਲੰਘੋ, ਫਿਰ ਉਹਨਾਂ ਪਛਾਣਾਂ ਲਈ ਦੂਜੀ ਪਾਸ:
ਰੈਡੈਕਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਧਾਂਚਾ ਰੱਖੋ। ਕਿਸਮਾਂ, ਸਕੀਮਾ, ਫੀਲਡ ਨਾਂ, ਸਥਿਤੀ ਕੋਡ ਅਤੇ ਉਦਾਹਰਨ payload ਠੀਕ ਛੱਡੋ, ਪਰ ਅਸਲੀ ਮੁੱਲ placeholders ਨਾਲ ਬਦਲੋ।
ਤੁਸੀਂ ਇਹ ਸਥਿਰ ਰੱਖਣ ਲਈ (ਖ਼ਾਸਕਰ ਦਬਾਅ ਹੇਠਾਂ) ਇੱਕ ਛੋਟਾ ਰੈਡੈਕਸ਼ਨ ਨਿਯਮ ਲਿਖੋ ਅਤੇ ਮੁੜ ਵਰਤੋਂ। ਟੀਮਾਂ ਲਈ, ਇਸਨੂੰ ਇਕ ਸਾਂਝਾ ਟੈਂਪਲੇਟ ਵਿੱਚ ਬਦਲੋ ਜਿਸ ਵਿੱਚ ਦੋ ਬਲਾਕ ਹੋਣ: “ਮੈਂ ਕੀ ਸਾਂਝਾ ਕਰ ਰਿਹਾ ਹਾਂ” (ਫਾਇਲਾਂ, ਫੰਕਸ਼ਨ, endpoints) ਅਤੇ “ਮੈਂ ਕੀ ਨਹੀਂ ਸਾਂਝਾ ਕਰ ਰਿਹਾ” (ਸੀਕ੍ਰੇਟਸ, ਪ੍ਰੋਡ ਡੇਟਾ, ਅੰਦਰੂਨੀ ਡੋਮੇਨ)।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਾਧੂ ਸੁਰੱਖਿਆ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਆਪਣੇ ਪ੍ਰਯੋਗ ਇਕ ਅਲੱਗ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕਰੋ ਅਤੇ ਬਦਲਾਅ ਨੂੰ ਰਿਵਰਸ ਕਰਨ ਲਾਇਕ ਰੱਖੋ। Koder.ai (koder.ai) ਵਿੱਚ, planning mode ਤੁਹਾਡੇ ਲਈ ਘੱਟੋ-ਘੱਟ ਪਰਿਵਰਤਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ snapshots ਤੇ rollback ਅਪ-ਡੋਣ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਕਰਨ ਲਈ ਸਹਾਇਕ ਹੁੰਦੇ ਹਨ।
ਹਮੇਸ਼ਾ ਉਹੋ ਚੋਟਾ ਹਿੱਸਾ ਸ਼ੇਅਰ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇ ਸਕੇ: ਫੇਲ ਹੋਣ ਵਾਲਾ इनਪੁਟ, ਉਮੀਦਿਤ ਬਨਾਮ ਅਸਲ ਆਉਟਪੁੱਟ, ਅਤੇ ਓਹ ਕੋਈ ਖਾਸ ਕੋਡ ਪਾਥ ਜੋ ਇਸ ਨਾਲ ਸਬੰਧਤ ਹੈ。
एक अच्छा डिफ़ॉल्ट समूह है:
ਨਹੀਂ ਪੇਸਟ ਕਰੋ:
ਜੇ ਇਹ ਕਿਸੇ ਅਜਿਹੇ ਵਿਅਕਤੀ ਨੂੰ ਲੌਗਿਨ ਕਰਨ, ਕਿਸੇ ਨਾਗਰਿਕ ਦੀ ਪਛਾਣ ਕਰਨ ਜਾਂ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਨਕਸ਼ਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ, ਤਾਂ ਇਸਨੂੰ ਰੈਡੈਕਟ ਜਾਂ ਸੰਖੇਪ ਕਰੋ।
ਪੜਚੋਲਣਯੋਗ placeholders ਵਰਤੋਂ ਤਾਂ ਕਿ ਫਲੋ ਪਾਠਯੋਗ ਰਹੇ।
ਉਦਾਹਰਨ ਸਕੀਮ:
TOKEN_1, TOKEN_2API_KEY_1USER_ID_1, ਜਦੋਂ bug parsing ਜਾਂ validation 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਤਾਂ ਫਾਰਮੈਟ ਨੂੰ ਬਚਾਓ।
ਆਮ ਕੇਸ:
8-4-4-4-12 ਪੈਟਰਨ ਰੱਖੋਇਸ ਨਾਲ ਤੁਸੀਂ ਕਹਿ ਸਕਦੇ ਹੋ “ਟੋਕਨ validation fail ਕਰ ਰਿਹਾ ਹੈ” ਬਿਨਾਂ ਅਸਲੀ ਵੈਲਯੂ ਦੀ ਰਿਕਵਾਲ ਕੀਤੇ।
ਕੀ ਨੂੰ ਰੱਖੋ ਅਤੇ ਕੀ ਬਦਲੋ:
JSON ਲਈ:
SQL ਲਈ:
ਉਦਾਹਰਨ:
ਉਸਨੂੰ خلاصہ ਕਰੋ ਜਿਸ ਵਿੱਚ ਇਨਪੁਟ, ਆਉਟਪੁੱਟ ਅਤੇ ਉਸ ਨਿਯਮ ਦੀ ਵਿਆਖਿਆ ਹੋਵੇ ਜੋ ਬੱਗ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾ ਰਿਹਾ ਹੈ।
ਪ੍ਰਯੋਗਤ ਸਮਰੀ 'ਚ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ:
ਇਸ ਨਾਲ ਤੁਸੀਂ ਅਕਸਰ ਇੱਕੋ ਜਿਹੀ ਡਿਬੱਗਿੰਗ ਵੈਲਯੂ ਪ੍ਰਾਪਤ ਕਰ ਲੈਦੇ ਹੋ ਬਿਨਾਂ ਆਪਣੀ implementation ਵੇਰਵਾ ਕਰਨ ਦੇ।
ਸਧਾਰਨ ਸੁਰੱਖਿਅਤ ਪ੍ਰੋੰਪਟ ਟੈਂਪਲੇਟ:
ਇਕ redaction ਨੋਟ ਵੀ ਸ਼ਾਮਲ ਕਰੋ:
“Redacted: tokens, emails, customer data, internal hostnames. Kept: endpoint paths, status codes, header names, exact error text.”
.env ਫਾਈਲਾਂ ਅਤੇ ਪੂਰੇ config dumps ਖਤਰਨਾਕ ਕਿਉਂ ਹਨ:
ਕਿਉਂਕਿ ਉਹ ਅਕਸਰ ਸਭ ਕੁਝ ਇੱਕੱਠੇ ਰੱਖਦੇ ਹਨ:
ਇਕ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਹੈ config ਟੈਮਪਲੇਟ:
ਇੰਕਰੀਮੈਂਟਲ disclosure ਵਰਤੋਂ:
ਇਹ ਸਕੋਪ ਨੂੰ ਛੋਟਾ ਰੱਖਦਾ ਹੈ ਅਤੇ ਧਿਆਨ ਵੱਡਾ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਅਕਸਮਾਤੀ ਲੀਕ ਨਾ ਹੋਵੇ।
ਇਕ ਵਰਤਣਯੋਗ ਬੰਡਲ:
ਫਿਰ ਪੁੱਛੋ:
“ਕੀ ਟਾਪ ਪ੍ਰੋਡਕਸ਼ਨ-ਵਿੱਚ-ਖਾਸ ਕਾਰਨ ਹਨ (clock skew, issuer/audience mismatch, signing key mismatch), ਅਤੇ ਹਰ ਇੱਕ ਦੀ ਪੁਸ਼ਟੀ ਲਈ ਇੱਕ ਸੂਚਿਤ ਚੈੱਕ ਕੀ ਹੈ?”
CUSTOMER_ID_1EMAIL_1ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਤਦ ਇੱਕ ਛੋਟਾ legend ਸ਼ਾਮِل ਕਰੋ:
TOKEN_1: Authorization bearer token ਜੋ /me 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈCUSTOMER_ID_1: ਡੇਟਾਬੇਸ ਲੁੱਕਅਪ ਵਿੱਚ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ identifierWHERE user_id = USER_ID_1 AND created_at > DATE_1<set> ਜਾਂ <redacted> ਨਾਲ ਬਦਲੋ