Claude Code ਲਈ ਸੰਵੇਦਨਸ਼ੀਲ ਸੰਦਰਭ ਘਟਾਉਣਾ — ਸੁਰੱਖਿਅਤ ਕੋਡਿੰਗ ਮਦਦ

ਕਿਉਂ Coding ਮਦਦ ਮੰਗਦਿਆਂ ਸੰਦਰਭ ਘਟਾਉਣਾ ਅਹੰਕਾਰਪੂਰਕ ਹੈ

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

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

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

• API ਕੁੰਜੀਆਂ, ਟੋਕਨ, ਪ੍ਰਾਈਵੇਟ ਕੀਜ਼, ਸੈਸ਼ਨ ਕੁਕੀਜ਼
• ਅੰਦਰੂਨੀ URLs, IPs, ਹੋਸਟਨੇਮ ਤੇ ਸਰਵਿਸ ਨਾਂ
• ਲੌਗਾਂ ਵਿੱਚ ਗਾਹਕ ਡੇਟਾ (ਈਮੇਲ, ਨਾਮ, ID, ਭੁਗਤਾਨ)
• ਉਹ ਵਪਾਰਕ ਲਾਜ਼ ਜਿਹੜਾ ਤੁਸੀਂ ਪ੍ਰਕਾਸ਼ਿਤ ਨਹੀਂ ਕਰਦੇ (ਮੂਲ ਪ੍ਰਾਈਸਿੰਗ, ਫਰੌਡ ਚੇਕ)
• ਸੁਰੱਖਿਆ ਸੰਬੰਧੀ ਵੇਰਵਾ (admin endpoints, feature flags, access patterns)

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

ਇੱਕ ਸਧਾਰਨ ਦਿਮਾਗੀ ਮਾਡਲ: ਸਹਾਇਕ ਨੂੰ ਇਕ ਬਾਹਰੀ ਸਹਿਯੋਗੀ ਵਜੋਂ ਸੋਚੋ ਜਿਸਨੂੰ ਤੁਹਾਡੀ ਪੂਰੀ ਰਿਪੋ ਦੀ ਲੋੜ ਨਹੀਂ। ਇੱਕ ਸਟੀਕ ਸਵਾਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ("ਇਹ ਬੇਨਤੀ 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] ਨਾਲ ਬਦਲੋ।

ਰੈਡੈਕਸ਼ਨ ਨਮੂਨੇ ਜੋ ਕੋਡ ਅਤੇ ਲੌਗ ਨੂੰ ਉਪਯੋਗੀ ਰੱਖਦੇ ਹਨ

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

ਨਮੂਨਾ 1: ਸਥਿਰ placeholders ਵਰਤੋਂ

ਇੱਕ 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 token
• CUSTOMER_ID_1: ਡੇਟਾਬੇਸ ਲੁੱਕਅਪ ਵਿੱਚ ਵਰਤਿਆ ਅੰਦਰੂਨੀ ਗਾਹਕ identifier

ਨਮੂਨਾ 2: ਜਦੋਂ ਫਾਰਮੈਟ ਮਹੱਤਵਪੂਰਕ ਹੋਵੇ, ਫਾਰਮੈਟ ਬਚਾਓ

ਕੁਝ ਬੱਗ ਲੰਬਾਈ ਅਤੇ ਢਾਂਚੇ ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ (parsing, validation, signature checks, regex)। ਉਹਨਾਂ ਕੇਸਾਂ ਵਿੱਚ, ਵਿਲੱਖਣ strings ਨੂੰ ਅਜਿਹੇ ਡਮੀ ਮੁੱਲ ਨਾਲ ਬਦਲੋ ਜੋ ਰੂਪ ਵਿੱਚ ਮਿਲਦੇ-ਜੁਲਦੇ ਹਨ।

ਉਦਾਹਰਨ:

• JWT-ਜਿਵੇਂ ਟੋਕਨ: ਤਿੰਨ ਡਾਟ-ਅਲੱਗ ਭਾਗ ਰੱਖੋ, ਸਮਾਨ ਲੰਬਾਈ
• UUID-ਜਿਵੇਂ strings: 8-4-4-4-12 ਪੈਟਰਨ ਰੱਖੋ
• Base64-ਜਿਵੇਂ ਬਲੌਬ: ਸਮਾਨ ਕਰੈਕਟਰ-ਸੈਟ ਅਤੇ ਲਗਭਗ ਲੰਬਾਈ ਰੱਖੋ

ਇਸ ਨਾਲ ਤੁਸੀਂ ਕਹਿ ਸਕਦੇ ਹੋ “ਟੋਕਨ validation fail ਕਰ ਰਿਹਾ ਹੈ” ਬਿਨਾਂ ਅਸਲੀ ਟੋਕਨ ਨੂੰ ਦਰਸਾਉਂਦੇ।

ਨਮੂਨਾ 3: ਮੂਲ ਧਾਂਚਾ ਬਚਾਓ ਪਰ ਮੁੱਲ ਰੈਡੈਕਟ ਕਰੋ

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
• ਹਟਾਓ: ਅਸਲੀ IDs, timestamps, ਈਮੇਲ, ਪਤੇ

ਨਮੂਨਾ 4: ਸੰਵੇਦਨਸ਼ੀਲ ਬਲੌਕਾਂ ਦੀ ਬਜਾਏ ਉਨ੍ਹਾਂ ਦਾ ਸੰਖੇਪ ਦਿਓ

ਜੇ ਇਕ ਫੰਕਸ਼ਨ ਵਿੱਚ ਵਪਾਰਕ ਨੀਤੀਆਂ ਜਾਂ 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 ਸਾਂਝਾ ਕੀਤੇ।

ਨਮੂਨਾ 5: ਇਕ ਛੋਟਾ ਰੈਡੈਕਸ਼ਨ ਨੋਟ ਸ਼ਾਮਲ ਕਰੋ

ਆਪਣੇ ਪ੍ਰੋੰਪਟ ਦੇ ਅੰਤ ਵਿੱਚ ਦੱਸੀਓ ਕਿ ਤੁਸੀਂ ਕੀ ਹਟਾਇਆ ਅਤੇ ਕੀ ਰੱਖਿਆ। ਇਹ ਬੈਕ-ਅੰਦ-ਫੋਰਥ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਸੰਭਾਵਨਾ ਘਟਾਉਂਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਹੋਰ ਪੇਸਟ ਕਰਨ ਲਈ ਬੇਨਤੀ ਕੀਤੀ ਜਾਵੇ।

ਉਦਾਹਰਨ:

“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, ਫਰੇਮਵਰਕ) ਦਿਓ। ਤੁਹਾਨੂੰ ਪੂਰੇ ਪ੍ਰੋਜੈਕਟ ਇਤਿਹਾਸ ਦੀ ਲੋੜ ਨਹੀਂ।

ਕੁਝ ਟੈਂਪਲੇਟ ਜੋ ਅਚ্ছে ਕੰਮ ਕਰਦੇ ਹਨ:

• “ਇਸ ਫੰਕਸ਼ਨ ਸਿਗਨੇਚਰ ਅਤੇ ਕਾਲਰ ਦੇ ਨਾਲ, ਇਸ error ਦੇ ਸਭ ਤੋਂ ਸੰਭਾਵਿਤ ਕਾਰਨ ਕੀ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਪਹਿਲਾਂ ਕੀ ਜਾਂਚਣਾ ਚਾਹੀਦਾ ਹੈ?” (ਕਿਰਪਾ ਕਰਕੇ ਸਿਰਫ ਸੰਬੰਧਤ ਫੰਕਸ਼ਨ ਅਤੇ ਕਾਲਰ ਸ਼ਾਮਿਲ ਕਰੋ)
• “ਮੈਂ ਇਹ ਰਿਕਵੇਸਟ ਭੇਜਦਾ ਹਾਂ (ਸੈਨਟਾਈਜ਼ਡ) ਅਤੇ ਇਹ ਰਿਸਪਾਂਸ ਮਿਲਦਾ ਹੈ (ਸੈਨਟਾਈਜ਼ਡ). ਸਰਵਰ ਇਹ ਸਥਿਤੀ ਕੋਡ ਕਿਉਂ ਵਾਪਸ ਕਰ ਰਿਹਾ ਹੈ?” (ਹੈਡਰ ਨਾਂ ਸ਼ਾਮਿਲ ਕਰੋ, auth ਵੈਲਯੂ ਹਟਾਓ)
• “ਇਥੇ ਰਿਪ੍ਰੋ ਕਦਮ, ਉਮੀਦਤ ਬਨਾਮ ਅਸਲ ਆਊਟਪੁੱਟ ਅਤੇ ਵਾਤਾਵਰਣ. 3 ਧਾਰ੍ਹਾਂ ਦੇ ਫੋਕਸਡ ਪ੍ਰਯੋਗ ਸੁਝਾਓ।”
• “ਇਹ ਲੌਗ ਅਨੁਛੇਦ ਫੇਲ ਦਰਸਾਉਂਦਾ ਹੈ ਨਾਲ 10 ਲਾਈਨਾਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ. ਸੱਸਲ ਸਪੋਰਟੀ ਸਪੱਸ਼ਟ ਕਰੋ ਅਤੇ ਇਕ ਨਵੀਂ ਲਾਈਨ ਜੋ ਮੈਂ ਜੋੜਾਂ.”
• “ਇਹ ਮੇਰੀ ਸੈਨਟਾਈਜ਼ਡ ਕਾਂਫਿਗ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਕੁੰਜੀਆਂ ਮੌਜੂਦ ਹਨ. ਇਹ ਮੱਥੇ ਕਿਹੜੀਆਂ ਗਲਤ-ਸੈੱਟ ਹੋ ਸਕਦੀਆਂ ਹਨ?” (ਕੰਫਿਗ ਕੀਜ਼, ਨਾ ਕਿ ਵੈਲਯੂਜ਼)

ਇਕ ਸੈਨਟਾਈਜ਼ਡ ਕਾਂਫਿਗ ਬਲਾਕ ਇੱਕ ਚੰਗਾ ਮਧਯਮ ਹੈ। ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਨੋਬਜ਼ ਹਨ ਬਿਨਾਂ ਸੀਕ੍ਰੇਟ ਖੋਲ੍ਹੇ:

# 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 ਸਧਾਰਣ ਰੱਖੋ:

• ਸਿਰਫ ਉਹੀ ਚੀਜ਼ ਕਾਪੀ ਕਰੋ ਜੋ ਸਮੱਸਿਆ ਨੂੰ ਦੁਹਰਾਉਂਦੀ (ਅਕਸਰ 1-3 ਫਾਇਲਾਂ, ਨਾਲ ਇੱਕ ਕਾਂਫਿਗ ਟੈਮਪਲੇਟ)
• ਇੱਕ ਛੋਟੀ README-ਸਟਾਈਲ ਨੋਟ ਜੋੜੋ: ਉਮੀਦਿਤ ਵਿਹਾਰ, ਅਸਲ ਵਿਹਾਰ, ਕਿਸ ਤਰ੍ਹਾਂ ਚਲਾਉਣਾ ਹੈ, ਕੀ जानकारੀਆਂ ਜਾਣ-ਬੁਝ ਕੇ ਲੁੱਕਾ ਦਿੱਤੀ ਗਈਆਂ ਹਨ
• ਸੀਕ੍ਰੇਟ ਅਤੇ endpoints ਸਟੱਬ ਕਰੋ: ਅਸਲੀ ਟੋਕਨ, ਕੁੰਜੀਆਂ ਅਤੇ ਹੋਸਟਨੇਮ placeholder ਜਾਂ example ਡੋਮੇਨ/localhost ਨਾਲ ਬਦਲੋ
• ਜੇ ਡੇਟਾ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਛੋਟੀ synthetic fixture ਸ਼ਾਮਿਲ ਕਰੋ (ਜਿਵੇਂ 10-20 ਰੋਜ਼ ਨਕਲੀ ਈਮੇਲਾਂ ਅਤੇ ਨਕਲੀ IDs), ਨਾ ਕਿ ਡੇਟਾਬੇਸ ਡੰਪ
• “ਜਿਵੇਂ-ਹੋ ਸਕੇ” ਚੀਜ਼ਾਂ ਹਟਾਓ: ਪੁਰਾਣੇ ਲੌਗ, ਗੈਰ-ਸੰਬੰਧਿਤ ਮੌਡੀਊਲ, ਨਕਲ ਵਰਜ਼ਨ

ਫੋਲਡਰ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਬਾਹਰੀ ਵ੍ਯਕਤੀ ਵਾਂਗੌ ਪੜ੍ਹੋ। ਜੇ ਕੋਈ ਫਾਇਲ ਨਿਰਧਾਰਤ ਸਮੱਸਿਆ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਦੀ, ਤਾਂ ਉਹ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।

ਜਦੋਂ ਤੁਸੀਂ ਰੈਡੈਕਟ ਕਰਦੇ ਹੋ, ਕੋਡ ਜਾਂ ਲੌਗ ਨੂੰ ਤੋੜੋ ਨਹੀਂ। ਮੁੱਲਾਂ ਨੂੰ ਉਹਨਾਂ ਦੀ ਕਿਸਮ ਅਤੇ ਸਿਰੰਜਚਾ ਨੂੰ ਬਚਾਉਂਦੇ ਹੋਏ ਅਸਾਨ placeholders ਨਾਲ ਬਦਲੋ। ਉਦਾਹਰਨ ਦੇ ਲਈ:

DATABASE_URL=postgres://user:[email protected]:5432/app

ਨਾਲ ਬਦਲੋ:

DATABASE_URL=postgres://user:REDACTED@localhost:5432/app

ਜੇ ਬੱਗ ਕਿਸੇ ਤੀਸਰੇ-ਪਾਰਟੀ ਦੇ ਜਵਾਬ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ README ਵਿੱਚ response shape ਲਿਖੋ ਅਤੇ ਇਕ ਸਿੰਥੇਟਿਕ JSON ਫਾਇਲ ਸ਼ਾਮਿਲ ਕਰੋ ਜੋ ਉਸਨੂੰ ਮਿਲਦਾ-ਜੁਲਦਾ ਹੋਵੇ। ਇਸ ਤਰ੍ਹਾਂ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਸਾਂਝਾ ਕੀਤੇ ਬਿਨਾਂ ਵੀ ਮਾਨਯੋਗ ਡੀਬੱਗਿੰਗ ਮਿਲ ਸਕਦੀ ਹੈ।

ਕਦਮ-ਦਰ-ਕਦਮ: ਸੁਰੱਖਿਆ-ਪਹਿਲਾ ਵਰਕਫਲੋ ਜਦੋਂ ਤੁਸੀਂ ਮਦਦ ਮੰਗ ਰਹੇ ਹੋ

ਇੱਕ ਦੁਹਰਾਊ ਲੂਪ ਵਰਤੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਦਬਾਅ ਹੇਠਾਂ improvisation ਨਾ ਕਰੋ।

1. ਪਹਿਲਾਂ ਦੋ ਵਾਕ ਲਿਖੋ।

   • ਸਮੱਸਿਆ ਦਾ ਬਿਆਨ: ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਕਿ ਕੀ ਤੂਟਿਆ ਹੋਇਆ ਹੈ।
   • ਸੀਮਾ: ਜੋ ਤੁਸੀਂ ਸਾਂਝਾ ਨਹੀਂ ਕਰੋਗੇ (ਉਦਾਹਰਨ: “No API keys, no customer data, no internal hostnames”).

2. ਨਿਊਨਤਮ ਇਨਪੁਟ ਇਕੱਠੇ ਕਰੋ। ਸਿਰਫ ਉਹੀ ਲੈ ਆਓ ਜੋ ਦੁਹਰਾਉਣ ਜਾਂ ਵਿਚਾਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ: ਫੇਲ ਹੋਣ ਵਾਲੇ ਲਾਈਨ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਛੋਟਾ snippet, ਸਹੀ error ਟੈਕਸਟ, ਸੰਬੰਧਤ ਵਰਜਨ ਅਤੇ 3-5 repro ਕਦਮ।

3. ਢਾਂਚਾ ਠੀਕ ਰੱਖਦੇ ਹੋਏ ਰੈਡੈਕਟ ਕਰੋ। ਸੀਕ੍ਰੇਟ ਨੂੰ placeholders ਨਾਲ ਬਦਲੋ ਅਤੇ ਉਹਨਾਂ ਪਢਾਂਚਿਆਂ ਨੂੰ ਰੱਖੋ। ਉਨ੍ਹਾਂ ਪਢਾਂਚਿਆਂ ਜੋ ਵਿਹਾਰ 'ਤੇ ਪ੍ਰਭਾਵ ਨਹੀਂ ਪਾ ਰਹੀਆਂ ਉਹਨਾਂ ਨੂੰ ਹਟਾਓ (ਪ੍ਰੋਜੈਕਟ ਨਾਂ, tenant IDs, ਈਮੇਲ)। placeholders ਸਥਿਰ ਰੱਖੋ।

   API_KEY=sk_live_...
   becomes
   API_KEY=<API_KEY>
   
   customer-1234-prod-db
   becomes
   <DB_HOST_PROD>
   

4. ਲਕੜੇ ਸਵਾਲ ਪੁੱਛੋ। “ਸਭ ਤੋਂ ਸੰਭਾਵਿਤ ਕਾਰਨ ਕੀ ਹੈ?” ਦੇ ਨਾਲ “ਮੈਂ ਕੀ ਬਦਲਾਂ?” ਜੋੜੋ। ਜੇ ਤੁਸੀਂ patch ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਕਿਸ਼ਤੀ ਨੂੰ ਲਿਮਟ ਕਰੋ ਅਤੇ ਮੰਨਿਆ ਜਾਵੇ ਇਹ ਮੰਨਤੀਆਂ ਲੇਬਲ ਹੋਣ।

5. ਲੋਕਲ ਤੌਰ 'ਤੇ ਵੇਰਿਫਾਈ ਕਰੋ, ਫਿਰ ਇੱਕ ਨਵਾਂ ਵੇਰਵਾ ਜੋੜੋ। ਸੁਝਾਅ ਨੂੰ ਟੈਸਟ ਕਰੋ। ਜੇ ਇਹ ਫੇਲ ਹੋਵੇ, ਤਾਂ ਸਿਰਫ਼ ਇੱਕ ਨਵੀਂ ਜਾਣਕਾਰੀ (ਅਗਲਾ ਸਟੈਕ ਟ੍ਰੇਸ ਲਾਈਨ, ਇਕ config ਫਲੈਗ, ਇਕ ਨੈਰੋਰੇਪ੍ਰੋ) ਜੋੜੋ। ਸਿੱਧੇ ਹੀ ਪੂਰਾ ਫਾਇਲ ਪੇਸਟ ਕਰਨ ਤੇ ਛਾਲ ਮਾਰੋ ਨਾ।

ਇਹ ਧੀਰੇ-ਧੀਰੇ ਖੁਲਾਸਾ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਅਸਲੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਸੀਕ੍ਰੇਟ ਅਤੇ ਗੈਰ-ਸੰਬੰਧਿਤ ਕੋਡ prompts ਤੋਂ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ।

ਉਦਾਹਰਨ: ਬਿਨਾਂ ਸੀਕ੍ਰੇਟ ਲਿਖੀਏ auth ਫੇਲ ਨੂੰ ਡੀਬੱਗ ਕਰੋ

ਆਮ ਸਥਿਤੀ: ਲੌਗਿਨ ਤੁਹਾਡੇ ਲੈਪਟੌਪ ਅਤੇ ਸਟੇਜਿੰਗ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਫੇਲ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਮਦਦ ਚਾਹੀਦੀ ਹੈ, ਪਰ ਤੁਸੀਂ ਅਸਲੀ ਟੋਕਨ, ਯੂਜ਼ਰ ਈਮੇਲ, ਅੰਦਰੂਨੀ ਹੋਸਟਨੇਮ ਜਾਂ ਪੂਰਾ auth middleware ਪੇਸਟ ਨਹੀਂ ਕਰ ਸਕਦੇ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਉਹ ਸਾਂਝਾ ਕਰੋ: request ਅਤੇ response shape, ਸਥਿਤੀ ਕੋਡ ਅਤੇ ਇੱਕ ਛੋਟਾ ਸਟੈਕ ਟ੍ਰੇਸ। ਜੇ JWT-ਸਬੰਧੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਨਾ-ਸੰਵੇਦਨਸ਼ੀਲ ਹੈਡਰ ਵੇਰਵੇ (ਜਿਵੇਂ ਉਮੀਦਿਤ algorithm) ਅਤੇ ਸਮੇਂ ਦੇ ਅੰਸ਼ (ਸਰਵਰ ਟਾਈਮ ਡ੍ਰਿਫਟ) ਵੀ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹੋ। ਹੋਰ ਕੁਝ ਵੀ placeholder ਵਿੱਚ ਬਦਲ ਦਿਓ।

ਇੱਕ ਸੁਰੱਖਿਅਤ ਬੰਡਲ ਅਕਸਰ ਸ਼ਾਮਿਲ ਹੁੰਦਾ ਹੈ:

• Request: method, path, ਆਮ ਹੈਡਰ (Authorization: "Bearer <JWT_REDACTED>"), ਅਤੇ ਬਾਡੀ ਫੀਲਡ ਨਾਂ (ਕੋਈ ਅਸਲ ਮੁੱਲ ਨਹੀਂ)
• Response: status (401/403), ਆਮ error ਕੋਡ/ਸੁਨੇਹਾ, ਅਤੇ ਇੱਕ correlation id ਜੇ ਇਹ ਕਿਸੇ ਯੂਜ਼ਰ ਨਾਲ ਜੁੜਿਆ ਨਹੀਂ
• Logs: ਫੇਲ ਦੇ ਆਲੇ-ਦੁਆਲੇ 5–10 ਲਾਈਨਾਂ, ਟੋਕਨ/ਈਮੇਲ/ਹੋਸਟ ਰੈਡੈਕਟ ਕੀਤੇ ਹੋਏ
• Stack trace: ਕੇਵਲ ਉੱਪਰਲੇ ਫਰੇਮ ਜਿੱਥੇ validation ਫੇਲ ਹੋ ਰਹੀ ਹੈ

ਫਿਰ ਇੱਕ ਫੋਕਸਡ ਸਵਾਲ ਪੁੱਛੋ। ਪ੍ਰੋਡਕਸ਼ਨ-ਕੇਵਲ 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 ਕਰਦਾ ਹੈ।

ਇੱਕ ਸਧਾਰਨ ਯੋਜਨਾ:

• ਸਰਵਰ ਸਮਾਂ ਅਤੇ ਟੋਕਨ exp/iat ਲੌਗ ਕਰੋ (ਕਦੇ ਵੀ ਕੱਚਾ ਟੋਕਨ ਨਹੀਂ)
• ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ issuer/audience/env ਕਾਂਫਿਗ ਮੁੱਲਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ (hashes ਜਾਂ ਰੈਡੈਕਟ ਕੀਤੇ ਸਤਰਾਂ ਵਜੋਂ)
• clock skew tolerance ਲਈ ਇੱਕ ਟੈਸਟ ਜੋੜੋ (ਉਦਾਹਰਨ: 60-120 ਸੈਕਿੰਡ)
• ਇੱਕ ਸਿੰਥੇਟਿਕ ਟੋਕਨ ਜੋ ਇੱਕ ਸੁਰੱਖਿਅਤ ਵਾਤਾਵਰਣ ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਹੈ ਨਾਲ ਦੁਹਰਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ
• ਪੁਸ਼ਟੀ ਹੋਣ ਤੋਂ ਬਾਅਦ ਅਸਥਾਈ ਲੌਗਿੰਗ ਹਟਾ ਦਿਓ

ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਜਾਲ

ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਪ੍ਰਾਈਵੇਸੀ ਦੇ ਫਾਇਦੇ ਗੁਆਉਣ ਦੀ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ “ਇਕ ਛੋਟੀ ਚੀਜ਼” ਪੇਸਟ ਕਰੋ ਜੋ ਆਹਿਸਤਾ-ਆਹਿਸਤਾ ਸਭ ਕੁਝ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ। ਪੂਰਾ .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” ਦੇ ਲਈ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਗਲਤ ਨਿ:ਸ਼ਚ ਮਿਲੇਗਾ। ਇਕ ਯੋਜਨਾ ਚੁਣੋ ਅਤੇ ਉਸਦੇ ਨਾਲ ਰਹੋ।

ਜੇ ਤੁਹਾਡਾ ਸੁਨੇਹਾ ਕਿਸੇ ਅਜਿਹੇ ਵਿਅਕਤੀ ਨੂੰ ਲੌਗਿਨ ਕਰਨ, ਸਰਵਰਾਂ ਦੀ ਸਥਿਤੀ ਪਛਾਣ ਕਰਨ ਜਾਂ ਗਾਹਕ ਪਛਾਣਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ ਤਾਂ ਇਹ ਹੋਰ ਇੱਕ ਪਾਸ ਦੌਰਾ ਲੋੜਦੀ ਹੈ।

ਛੋਟੀ ਚੈਕਲਿਸਟ ਅਤੇ ਅਗਲੇ ਕਦਮ

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

ਸੀਕ੍ਰੇਟਸ ਲਈ ਇੱਕ ਪਾਸ ਲੰਘੋ, ਫਿਰ ਉਹਨਾਂ ਪਛਾਣਾਂ ਲਈ ਦੂਜੀ ਪਾਸ:

• ਕੁਝ ਵੀ ਜੋ ਪ੍ਰਵੇਸ਼ ਦਾ ਹੱਕ ਦਿੰਦਾ ਹੈ ਹਟਾਓ: API ਕੁੰਜੀਆਂ, OAuth client secrets, ਪ੍ਰਾਈਵੇਟ ਕੀ, ਸੈਸ਼ਨ कुਕੀਜ਼, refresh tokens, auth headers.
• ਛੁਪੇ ਐਕਸੈਸ ਰਾਸਤੇ ਹਟਾਓ: signed URLs, pre-signed upload links, webhook secrets, password reset links, invite links.
• ਅੰਦਰੂਨੀ identifiers ਬਦਲੋ: ਅੰਦਰੂਨੀ ਡੋਮੇਨ, ਹੋਸਟਨੇਮ, IPs, ਅਕਾਊਂਟ IDs, ਯੂਜ਼ਰ IDs, org IDs, order IDs, ticket numbers.
• ਲੌਗ ਸੈਨਟਾਈਜ਼ ਕਰੋ: request bodies, query strings, stack traces ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਫਾਇਲ ਪਾਥ, ਯੂਜ਼ਰਨੇਮ ਜਾਂ environment variables ਹਨ.
• ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਕੋਪ ਨਿਊਨਤਮ ਹੈ: ਸਿਰਫ ਫੇਲ ਹੋਣ ਵਾਲਾ ਪਾਥ, ਕਾਲਰ ਅਤੇ ਇਨਪੁਟ/ਆਉਟਪੁੱਟ ਕਾਂਟਰੈਕਟ।

ਰੈਡੈਕਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਧਾਂਚਾ ਰੱਖੋ। ਕਿਸਮਾਂ, ਸਕੀਮਾ, ਫੀਲਡ ਨਾਂ, ਸਥਿਤੀ ਕੋਡ ਅਤੇ ਉਦਾਹਰਨ payload ਠੀਕ ਛੱਡੋ, ਪਰ ਅਸਲੀ ਮੁੱਲ placeholders ਨਾਲ ਬਦਲੋ।

ਤੁਸੀਂ ਇਹ ਸਥਿਰ ਰੱਖਣ ਲਈ (ਖ਼ਾਸਕਰ ਦਬਾਅ ਹੇਠਾਂ) ਇੱਕ ਛੋਟਾ ਰੈਡੈਕਸ਼ਨ ਨਿਯਮ ਲਿਖੋ ਅਤੇ ਮੁੜ ਵਰਤੋਂ। ਟੀਮਾਂ ਲਈ, ਇਸਨੂੰ ਇਕ ਸਾਂਝਾ ਟੈਂਪਲੇਟ ਵਿੱਚ ਬਦਲੋ ਜਿਸ ਵਿੱਚ ਦੋ ਬਲਾਕ ਹੋਣ: “ਮੈਂ ਕੀ ਸਾਂਝਾ ਕਰ ਰਿਹਾ ਹਾਂ” (ਫਾਇਲਾਂ, ਫੰਕਸ਼ਨ, endpoints) ਅਤੇ “ਮੈਂ ਕੀ ਨਹੀਂ ਸਾਂਝਾ ਕਰ ਰਿਹਾ” (ਸੀਕ੍ਰੇਟਸ, ਪ੍ਰੋਡ ਡੇਟਾ, ਅੰਦਰੂਨੀ ਡੋਮੇਨ)।

ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਾਧੂ ਸੁਰੱਖਿਆ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਆਪਣੇ ਪ੍ਰਯੋਗ ਇਕ ਅਲੱਗ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕਰੋ ਅਤੇ ਬਦਲਾਅ ਨੂੰ ਰਿਵਰਸ ਕਰਨ ਲਾਇਕ ਰੱਖੋ। Koder.ai (koder.ai) ਵਿੱਚ, planning mode ਤੁਹਾਡੇ ਲਈ ਘੱਟੋ-ਘੱਟ ਪਰਿਵਰਤਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ snapshots ਤੇ rollback ਅਪ-ਡੋਣ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਕਰਨ ਲਈ ਸਹਾਇਕ ਹੁੰਦੇ ਹਨ।