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 ലക്ഷ്യസ്ഥാനം പഴയ കൈമാറ്റത്തെ പിന്നീടു കാക്കുന്നില്ല. സേവനത്തിന് യോജിച്ച കൈമാറ്റരീതിയും പ്രാമാണീകരണവും തിരഞ്ഞെടുക്കുക; അറിയാത്ത പൊതു പ്രോക്സിക്ക് സ്വകാര്യ അക്കൗണ്ടുകൾ അയയ്ക്കരുത്.
വിശദമായ ലോഗുകൾ പങ്കിടുന്നതിനുമുമ്പ് നോക്കുക. സാധാരണ ലോഗിൻ ഫീൽഡുകൾ ഉപകരണം മറച്ചാലും ഉപയോക്തൃനാമങ്ങൾ, ആന്തരിക എൻഡ്പോയിന്റ് പേരുകൾ, കുക്കികൾ അല്ലെങ്കിൽ മറ്റു തിരിച്ചറിയൽ വിവരങ്ങൾ ശേഷിക്കാം.