HTTP 407 ή 401: ποια σύνδεση χρήστη αποτυγχάνει;

Το 407 ζητά ταυτοποίηση στον proxy. Το 401 ζητά ταυτοποίηση για τον πόρο προορισμού. Ένα αίτημα μπορεί να συναντήσει και τα δύο, οπότε εντοπίστε ποιος ρωτά πριν δώσετε κωδικό.

Συγκρίνετε την κατάσταση και τις κεφαλίδες πρόκλησης ταυτοποίησης

Η κατάσταση είναι βασική πρώτη ένδειξη, αλλά εξετάστε όλη την ανταλλαγή. Ο αριθμός 407 στο κείμενο μιας σελίδας δεν ισοδυναμεί με πραγματική απόκριση HTTP 407. Αντίστοιχα, μια προσαρμοσμένη σελίδα σύνδεσης μπορεί να επιστρέφει 200 και να απαιτεί ακόμη ταυτοποίηση στο επίπεδο εφαρμογής.

Γιατί το HTTPS μπορεί να αποτύχει με 407 πριν φτάσει στον ιστότοπο

Όταν ένας συνηθισμένος HTTP proxy μεταφέρει αίτημα HTTPS, ο πελάτης συνήθως ζητά πρώτα σήραγγα CONNECT. Ο proxy μπορεί να ζητήσει ταυτοποίηση για αυτό το αίτημα CONNECT. Αν δεν ολοκληρωθεί, η συνεδρία TLS με τον προορισμό δεν έχει ακόμη δημιουργηθεί μέσω της σήραγγας. Η αλλαγή του API token του ιστοτόπου μάλλον δεν θα διορθώσει αυτό το στάδιο.

Χρησιμοποιήστε αίτημα με αναλυτική έξοδο για να εντοπίσετε την πρόκληση:

curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/

Αντικαταστήστε το τοπικό σημείο ακρόασης με το δικό σας και διαβάστε την πρώτη πρόκληση στο αρχείο καταγραφής. Το 407 κατά το CONNECT προηγείται του TLS προορισμού· ένα μεταγενέστερο 401 μπορεί να ακολουθήσει την επιτυχή δημιουργία της σήραγγας.

Δώστε τα διαπιστευτήρια από τη διεπαφή του proxy

Για τελικό σημείο και λογαριασμό από διαχειριστή που εμπιστεύεστε, το curl μπορεί να διαπραγματευτεί το σχήμα ταυτοποίησης του proxy και να ζητήσει τον κωδικό που λείπει:

curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/

Αντικαταστήστε το τελικό σημείο και τον χρήστη του παραδείγματος με τα στοιχεία της υπηρεσίας που δικαιούστε να χρησιμοποιείτε. Ορίζοντας μόνο χρήστη αποφεύγετε τον κωδικό απευθείας στην παραπάνω εντολή. Οι υποστηριζόμενες μέθοδοι ποικίλλουν ανά build του curl και proxy· αν η διαπραγμάτευση αποτύχει, ελέγξτε την πραγματική πρόκληση και τις δυνατότητες του build.

Η επιλογή ταυτοποίησης του proxy είναι ξεχωριστή από την επιλογή χρήστη στον αρχικό διακομιστή του curl. Μην προσθέτετε κεφαλίδα Authorization για τον αρχικό διακομιστή αντί απάντησης στην πρόκληση του proxy. Επίσης, μην προωθείτε χειροκίνητα κεφαλίδες διαπιστευτηρίων του proxy σε άσχετα αιτήματα και μην τις αποθηκεύετε σε κεφαλίδες κοινές για όλη την εφαρμογή.

Αν ο proxy συνεχίζει να επιστρέφει 407

• Επιβεβαιώστε ότι χρησιμοποιείτε τον σωστό κεντρικό υπολογιστή και θύρα του proxy.
• Ελέγξτε τα σχήματα που ανακοινώνει ο proxy αντί να υποθέτετε Basic.
• Επιβεβαιώστε την κατάσταση του λογαριασμού και τυχόν ειδική μορφή ονόματος χρήστη.
• Ελέγξτε τη μεταβίβαση ειδικών χαρακτήρων αν τα διαπιστευτήρια βρίσκονται σε URL.
• Εξακριβώστε αν η εταιρική ταυτοποίηση που ενσωματώνεται στο πρόγραμμα περιήγησης χρειάζεται υποστήριξη από το περιβάλλον εκτέλεσης ή την πλατφόρμα.
• Όταν τα στοιχεία του πελάτη δεν αρκούν, ζητήστε από τον διαχειριστή αναγνωριστικό αιτήματος ή εγγραφή διακομιστή χωρίς ευαίσθητα δεδομένα.

Το 403 ή η άρνηση CONNECT μπορεί να είναι απόφαση πολιτικής πρόσβασης ακόμη και μετά από επιτυχή σύνδεση. Περισσότερες δοκιμές κωδικών δεν δίνουν πρόσβαση σε απαγορευμένο προορισμό.

Το HTTPS προορισμού δεν προστατεύει κάθε ανταλλαγή διαπιστευτηρίων του proxy

Η ταυτοποίηση του proxy μπορεί να συμβεί πριν δημιουργηθεί το TLS προορισμού. Αν η σύνδεση στον ίδιο τον proxy είναι μη κρυπτογραφημένη και η μέθοδος εκθέτει εκεί επαναχρησιμοποιήσιμα διαπιστευτήρια, ο HTTPS προορισμός δεν προστατεύει αναδρομικά αυτή την ανταλλαγή. Επιλέξτε κατάλληλα για την υπηρεσία μεταφορά και ταυτοποίηση· μην στέλνετε ιδιωτικούς λογαριασμούς σε άγνωστο δημόσιο proxy.

Ελέγξτε τα αναλυτικά αρχεία καταγραφής πριν τα κοινοποιήσετε. Ακόμη κι αν το εργαλείο καλύπτει συνήθη πεδία διαπιστευτηρίων, μπορεί να παραμένουν χρήστες, ονόματα εσωτερικών τελικών σημείων, cookies ή άλλα αναγνωριστικά δεδομένα.