ਪ੍ਰੌਕਸੀ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਵਿੱਚ ਡੋਮੇਨ-ਯੋਗ ਵਰਤੋਂਕਾਰ ਨਾਮ
ਅਸਪਸ਼ਟ ਖਾਤਾ ਨਾਮ ਨੂੰ ਵੱਖਰੇ ਡੋਮੇਨ ਖੇਤਰ ਵਾਲੇ API ਤੋਂ ਵੱਖਰਾ ਪਛਾਣੋ, ਅਤੇ ਸਿਰਫ਼ URL ਵਾਕ-ਰਚਨਾ ਪੂਰੀ ਕਰਨ ਲਈ ਖਾਤਾ ਪਛਾਣ ਬਦਲਣ ਤੋਂ ਬਚੋ।
ਇੱਕ ਜਵਾਬ ਕਹਿੰਦਾ ਹੈ DOMAIN\ ਹਟਾਓ। ਦੂਜਾ ਕਹਿੰਦਾ ਹੈ ਇਸ ਨੂੰ ਜੋੜੋ। ਦੋਵੇਂ ਬਦਲਾਅ ਤੁਹਾਡੇ ਪ੍ਰੌਕਸੀ ਲਈ ਗਲਤ ਹੋ ਸਕਦੇ ਹਨ।
ਦੋ ਸਵਾਲ ਹਨ: ਸੇਵਾ ਕਿਹੜੀ ਪਛਾਣ ਦੀ ਉਮੀਦ ਕਰਦੀ ਹੈ, ਅਤੇ ਚੁਣੀ ਗਈ API ਉਸ ਪਛਾਣ ਨੂੰ ਕਿਵੇਂ ਦਰਸਾਉਂਦੀ ਹੈ।
| ਇੰਟਰਫ਼ੇਸ | ਕੀ ਨਿਰਧਾਰਿਤ ਕਰਨਾ ਹੈ |
|---|---|
| ਇੱਕੋ ਖਾਤਾ-ਨਾਮ ਖੇਤਰ | ਓਪਰੇਟਰ ਵੱਲੋਂ ਸਵੀਕਾਰ ਕੀਤੀ ਸਹੀ ਖਾਤਾ ਵਾਕ-ਰਚਨਾ |
| ਡੋਮੇਨ ਖੇਤਰ ਵਾਲੀ ਪ੍ਰਮਾਣ API | ਕੀ ਡੋਮੇਨ ਅਤੇ ਵਰਤੋਂਕਾਰ ਨਾਮ ਵੱਖਰੇ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ |
| URI ਦੇ ਅੰਦਰ ਪ੍ਰਮਾਣ ਭਾਗ | ਇੱਛਤ ਮੁੱਲ ਉਸ ਕੰਟੇਨਰ ਲਈ ਕਿਵੇਂ ਐਨਕੋਡ ਕਰਨੇ ਹਨ |
ਉਦਾਹਰਨ ਲਈ, .NET ਵੱਖਰੇ ਵਰਤੋਂਕਾਰ ਨਾਮ, ਪਾਸਵਰਡ ਅਤੇ ਡੋਮੇਨ ਆਰਗਿਊਮੈਂਟ ਵਾਲਾ NetworkCredential ਕੰਸਟ੍ਰਕਟਰ ਦਿੰਦਾ ਹੈ। ਡੋਮੇਨ ਨੂੰ ਬਿਨਾਂ ਭੇਦਭਾਵ ਦੋ ਖੇਤਰਾਂ ਵਿੱਚ ਰੱਖਣਾ ਏਕੀਕ੍ਰਿਤ ਪ੍ਰਮਾਣੀਕਰਨ ਸੰਰਚਿਤ ਕਰਨ ਦਾ ਸੁਵਾਹਕ ਢੰਗ ਨਹੀਂ ਹੈ।
Basic ਪ੍ਰਮਾਣੀਕਰਨ ਦੂਜਾ ਮਾਮਲਾ ਹੈ: ਸਰਵਰ ਦਿੱਤੇ ਖਾਤਾ ਪਾਠ ਦੀ ਵਿਆਖਿਆ ਆਪਣੀ ਨੀਤੀ ਅਨੁਸਾਰ ਕਰਦਾ ਹੈ। ਇੱਕੋ ਨੈੱਟਵਰਕ 'ਤੇ ਹੋਣਾ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਡੋਮੇਨ ਅਗੇਤਰ ਅੰਤਰਨਿਹਿਤ ਹੈ। ਅਤੇ ਡੋਮੇਨ-ਯੋਗ ਨਾਮ ਵੀ ਆਪਣੇ ਆਪ ਵੱਖਰਾ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰੋਟੋਕੋਲ ਨਹੀਂ ਹੁੰਦਾ।
URL ਐਸਕੇਪਿੰਗ ਨੂੰ ਇੱਛਤ ਖਾਤਾ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਇਸ ਨੂੰ ਬਦਲਣਾ। ਸਰੋਤ-ਭਾਸ਼ਾ ਦੀ ਸਤਰ ਵਿੱਚ ਬੈਕਸਲੈਸ਼, ਖਾਤਾ ਨਾਮ ਵਿੱਚ ਬੈਕਸਲੈਸ਼ ਅਤੇ URI ਦੇ ਅੰਦਰ ਇਸ ਦੀ ਪ੍ਰਤੀਸ਼ਤ-ਐਨਕੋਡਡ ਪੇਸ਼ਕਾਰੀ ਵੱਖਰੀਆਂ ਪਰਤਾਂ ਹਨ।
ਓਪਰੇਟਰ ਤੋਂ ਸਵੀਕਾਰਯੋਗ ਪਛਾਣ-ਰੂਪ ਅਤੇ ਸਕੀਮ ਲਵੋ, ਫਿਰ ਸੰਬੰਧਿਤ ਪ੍ਰਮਾਣ ਇੰਟਰਫ਼ੇਸ ਵਰਤੋ। ਛੋਟੇ ਨਾਮ, ਡੋਮੇਨ ਨਾਮ ਅਤੇ ਈਮੇਲ ਵਰਗੇ ਨਾਮ ਵਿਚਕਾਰ ਬੇਤਰਤੀਬੇ ਬਦਲਾਅ ਮੂਲ 407 ਬਾਰੇ ਕਮਜ਼ੋਰ ਸਬੂਤ ਬਣਾਉਂਦਾ ਹੈ।