HTTP 407 hay 401: lần đăng nhập nào đang thất bại?
Phân biệt xác thực proxy với xác thực trang web, kiểm tra đúng header và tránh gửi thông tin đăng nhập cho sai bên.
407 yêu cầu bạn xác thực với proxy. 401 yêu cầu xác thực cho tài nguyên đích. Một yêu cầu có thể gặp cả hai, nên hãy xác định ai đang yêu cầu trước khi cung cấp mật khẩu.
Đối chiếu trạng thái và header yêu cầu xác thực
| Phản hồi | Header yêu cầu xác thực | Header thông tin đăng nhập | Bên liên quan |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Proxy trung gian |
| 401 Unauthorized | WWW-Authenticate | Authorization | Luồng xác thực của tài nguyên gốc |
Trạng thái là manh mối đầu tiên quan trọng, nhưng cần xem toàn bộ trao đổi. Số 407 trong nội dung trang không tương đương phản hồi HTTP 407 thực sự. Tương tự, trang đăng nhập tùy chỉnh có thể trả về 200 mà vẫn yêu cầu xác thực ở tầng ứng dụng.
Vì sao HTTPS có thể thất bại với 407 trước khi tới trang web
Khi proxy HTTP thông thường chuyển yêu cầu HTTPS, máy khách thường đề nghị tạo đường hầm CONNECT trước. Proxy có thể yêu cầu xác thực chính yêu cầu CONNECT đó. Nếu chưa hoàn tất, phiên TLS với đích qua đường hầm vẫn chưa được thiết lập. Đổi token API của trang web vì thế khó sửa được giai đoạn này.
Dùng đầu ra chi tiết để xem yêu cầu xác thực xuất hiện ở đâu:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Thay bộ lắng nghe cục bộ bằng của bạn rồi đọc yêu cầu xác thực đầu tiên trong nhật ký. 407 trong CONNECT xuất hiện trước TLS đích; 401 sau đó có thể xuất hiện khi đường hầm đã thiết lập thành công.
Cung cấp thông tin proxy qua giao diện dành cho proxy
Với điểm cuối và tài khoản do quản trị viên tin cậy cung cấp, curl có thể thương lượng cơ chế xác thực proxy và hỏi mật khẩu còn thiếu:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Thay điểm cuối và người dùng ví dụ bằng thông tin dịch vụ bạn được phép dùng. Chỉ chỉ định người dùng sẽ tránh đặt mật khẩu ngay trong lệnh ở trên. Phương thức hỗ trợ có thể khác theo bản dựng curl và proxy; nếu thương lượng thất bại, kiểm tra yêu cầu thực tế và khả năng của bản dựng.
Tùy chọn xác thực proxy tách biệt với tùy chọn xác thực người dùng máy chủ gốc của curl. Đừng thêm header Authorization dành cho gốc để thay cho phản hồi yêu cầu xác thực của proxy. Cũng tránh tự chuyển header thông tin đăng nhập proxy sang yêu cầu không liên quan hoặc lưu chúng trong header dùng lại trên toàn ứng dụng.
Nếu proxy liên tục trả về 407
- Xác nhận đúng máy chủ và cổng proxy dự định dùng.
- Kiểm tra cơ chế proxy công bố thay vì mặc định là Basic.
- Xác nhận trạng thái tài khoản và định dạng người dùng cụ thể nếu dịch vụ yêu cầu.
- Kiểm tra cách truyền ký tự đặc biệt nếu thông tin nằm trong URL.
- Xác định liệu xác thực doanh nghiệp tích hợp trình duyệt có cần hỗ trợ của môi trường chạy hay nền tảng không.
- Khi bằng chứng phía máy khách không đủ, nhờ quản trị viên cung cấp mã yêu cầu hoặc mục nhật ký máy chủ đã loại dữ liệu nhạy cảm.
403 hoặc CONNECT bị từ chối có thể là quyết định của chính sách truy cập dù đã đăng nhập thành công. Thử thêm mật khẩu không cấp quyền vào đích bị cấm.
HTTPS của đích không bảo vệ mọi trao đổi thông tin đăng nhập proxy
Xác thực proxy có thể diễn ra trước TLS đích. Nếu kết nối tới chính proxy không mã hóa và phương thức làm lộ thông tin có thể tái sử dụng trên đoạn đó, đích HTTPS không bảo vệ ngược lại trao đổi đã xảy ra. Chọn cách truyền và cơ chế xác thực phù hợp với dịch vụ; đừng gửi tài khoản riêng cho proxy công cộng không rõ nguồn.
Xem lại nhật ký chi tiết trước khi chia sẻ. Dù công cụ che các trường đăng nhập thông dụng, nhật ký vẫn có thể chứa người dùng, tên điểm cuối nội bộ, cookie hoặc dữ liệu nhận dạng khác.