HTTP 407 அல்லது 401: எந்த உள்நுழைவு தோல்வியடைகிறது?
ப்ராக்ஸி அங்கீகாரத்தையும் வலைத்தள அங்கீகாரத்தையும் பிரித்தறிந்து, சரியான தலைப்புகளைப் பார்த்து, தவறான தரப்புக்குச் சான்றுகளை அனுப்புவதைத் தவிர்க்கவும்.
407 ப்ராக்ஸியிடம் அங்கீகாரம் கோருகிறது. 401 இலக்கு வளத்துக்கான அங்கீகாரத்தைக் கோருகிறது. ஒரே கோரிக்கையில் இரண்டும் வரலாம்; கடவுச்சொல் தருவதற்கு முன் யார் கேட்கிறார்கள் என்பதை அறியுங்கள்.
நிலையையும் அங்கீகாரச் சவால் தலைப்புகளையும் ஒப்பிடுங்கள்
| பதில் | சவால் தலைப்பு | உள்நுழைவுச் சான்றுத் தலைப்பு | சம்பந்தப்பட்ட தரப்பு |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | இடையில் உள்ள ப்ராக்ஸி |
| 401 Unauthorized | WWW-Authenticate | Authorization | மூல வளத்தின் அங்கீகார நடைமுறை |
நிலைக் குறியீடு முக்கியமான முதல் தடயம்; முழுப் பரிமாற்றத்தையும் பாருங்கள். பக்க உரையில் 407 இருப்பது உண்மையான HTTP 407 பதிலுக்கு இணையானதல்ல. அதேபோல் தனிப்பயன் உள்நுழைவுப் பக்கம் 200 அளித்தும் பயன்பாட்டு அடுக்கில் அங்கீகாரம் கோரலாம்.
வலைத்தளத்தை அடையும்முன் HTTPS ஏன் 407 உடன் தோல்வியடையலாம்?
வழக்கமான HTTP ப்ராக்ஸி HTTPS கோரிக்கையைக் கொண்டு செல்லும்போது, கிளையன்ட் பொதுவாக முதலில் CONNECT சுரங்கம் கோருகிறது. ப்ராக்ஸி அந்த CONNECT கோரிக்கைக்கே அங்கீகாரம் கேட்கலாம். அது முடிவடையவில்லை என்றால் இலக்கின் TLS அமர்வு சுரங்கம் வழியாக இன்னும் உருவாகவில்லை. வலைத்தள API டோக்கனை மாற்றுவது இந்தக் கட்டத்தைச் சரிசெய்ய வாய்ப்புக் குறைவு.
விரிவான வெளியீட்டில் சவால் எங்கே வருகிறது என்பதைப் பாருங்கள்:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/உள்ளூர் லிஸனரை உங்களுடையதாக மாற்றி, பதிவின் முதல் சவாலைப் படியுங்கள். CONNECT நேரத்து 407 இலக்கின் TLS-க்கு முன்னதாக வரும்; வெற்றிகரமான சுரங்கத்திற்குப் பிறகு 401 வரலாம்.
ப்ராக்ஸிச் சான்றுகளை அதன் இடைமுகம் வழியாகக் கொடுங்கள்
நம்பகமான நிர்வாகி கொடுத்த முனையம் மற்றும் கணக்குக்கு curl அங்கீகார முறையைப் பேசி முடிவு செய்து, கொடுக்கப்படாத கடவுச்சொல்லைக் கேட்கலாம்:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/எடுத்துக்காட்டு முனையத்தையும் பயனரையும் அனுமதிக்கப்பட்ட சேவையின் விவரங்களால் மாற்றுங்கள். பயனரை மட்டும் குறிப்பிட்டால் மேலுள்ள கட்டளையில் நேரடியாகக் கடவுச்சொல் இருக்காது. curl உருவாக்கம் மற்றும் ப்ராக்ஸியைப் பொறுத்து முறைகள் மாறலாம்; பேச்சுவார்த்தை தோல்வியடைந்தால் உண்மையான சவாலையும் உருவாக்கத்தின் திறனையும் பாருங்கள்.
ப்ராக்ஸி அங்கீகார விருப்பம் curl-இன் மூலச் சேவையகப் பயனர் அங்கீகாரத்திலிருந்து தனியானது. ப்ராக்ஸி சவாலுக்கான பதிலுக்குப் பதிலாக மூலத்துக்கான Authorization தலைப்பைச் சேர்க்காதீர்கள். ப்ராக்ஸிச் சான்றுத் தலைப்புகளை தொடர்பில்லாத கோரிக்கைகளுக்குக் கையால் அனுப்பவோ, செயலி முழுவதும் மறுபயன்படும் தலைப்புகளில் சேமிக்கவோ வேண்டாம்.
ப்ராக்ஸி தொடர்ந்து 407 அளித்தால்
- எதிர்பார்த்த ப்ராக்ஸி ஹோஸ்ட்டையும் போர்ட்டையும் பயன்படுத்துவதை உறுதிசெய்யுங்கள்.
- Basic என்று ஊகிக்காமல் ப்ராக்ஸி அறிவிக்கும் முறைகளைப் பாருங்கள்.
- கணக்கின் நிலை மற்றும் சேவை எதிர்பார்க்கும் பயனர் பெயர் வடிவத்தை உறுதிசெய்யுங்கள்.
- சான்றுகள் URL-இல் இருந்தால் சிறப்பு எழுத்துகள் எவ்வாறு அனுப்பப்படுகின்றன என்பதைப் பாருங்கள்.
- உலாவியுடன் இணைந்த நிறுவன அங்கீகாரத்திற்கு இயக்கச்சூழல் அல்லது தள ஆதரவு வேண்டுமா என அறியுங்கள்.
- கிளையன்ட் ஆதாரம் போதாவிட்டால் நுணுக்கமான தகவல் அகற்றப்பட்ட கோரிக்கை அடையாளம் அல்லது சேவையகப் பதிவை நிர்வாகியிடம் கேளுங்கள்.
வெற்றிகரமான உள்நுழைவுக்குப் பிறகும் 403 அல்லது மறுக்கப்பட்ட CONNECT அணுகல் கொள்கையின் முடிவாக இருக்கலாம். மேலும் கடவுச்சொற்களை முயன்றால் தடைசெய்யப்பட்ட இலக்குக்கு அனுமதி கிடைக்காது.
இலக்கின் HTTPS ஒவ்வொரு ப்ராக்ஸிச் சான்றுப் பரிமாற்றத்தையும் காப்பதில்லை
ப்ராக்ஸி அங்கீகாரம் இலக்கின் TLS உருவாகும்முன் நிகழலாம். ப்ராக்ஸியுடனான இணைப்பே மறையாக்கமின்றி இருந்து, முறை அதில் மறுபயன்படும் சான்றுகளை வெளிப்படுத்தினால், HTTPS இலக்கு முந்தைய பரிமாற்றத்துக்குப் பின்னோக்கிப் பாதுகாப்பளிக்காது. சேவைக்கு ஏற்ற பரிமாற்ற முறையையும் அங்கீகாரத்தையும் தேர்ந்தெடுங்கள்; அறியாத பொதுப் ப்ராக்ஸிக்கு தனிப்பட்ட கணக்குகளை அனுப்பாதீர்கள்.
விரிவான பதிவுகளைப் பகிரும்முன் பாருங்கள். வழக்கமான சான்றுப் புலங்களை கருவி மறைத்தாலும் பயனர் பெயர்கள், உள் முனையப் பெயர்கள், குக்கிகள் அல்லது வேறு அடையாளத் தகவல்கள் இருக்கலாம்.