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 ગંતવ્ય અગાઉની આપલેને પાછળથી સુરક્ષિત કરતું નથી. સેવા અનુસાર ટ્રાન્સપોર્ટ અને પ્રમાણીકરણ પસંદ કરો; અજાણી જાહેર પ્રોક્સીને અંગત ખાતાં ન મોકલો.
વિગતવાર લૉગ શેર કરતાં પહેલાં જુઓ. સામાન્ય લૉગઇન ક્ષેત્રો ઢંકાય તો પણ વપરાશકર્તા નામ, આંતરિક એન્ડપોઇન્ટ નામ, કુકી કે અન્ય ઓળખ માહિતી રહી શકે છે.