Câu hỏi Xác thực mã thông báo HTTP và trình chặn cơ bản


Tôi hiện đang phát triển một REST-API được bảo vệ HTTP-Basic cho môi trường phát triển. Khi xác thực thực được thực hiện thông qua một mã thông báo, tôi vẫn đang cố gắng tìm ra cách gửi hai tiêu đề ủy quyền.

Tôi đã thử cái này:

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Authorization: Bearer mytoken123"

Ví dụ, tôi có thể vô hiệu hóa HTTP-Authentication cho IP của mình nhưng vì tôi thường làm việc trong các môi trường khác nhau với IP động, đây không phải là giải pháp tốt. Vì vậy, tôi thiếu một cái gì đó?


76
2018-03-06 16:16


gốc


Tôi cần phải xác thực thông qua HTTP cơ bản như máy chủ Dev được bảo vệ với nó và tôi cần xác thực dựa trên mã thông báo cho api. Nhưng khi tôi sử dụng curl để kiểm tra api, tôi cần một cách để gửi cả hai tiêu đề xác thực. Vì vậy, một trong những đầu tiên (cơ bản) để vượt qua HTTP cơ bản và thứ hai (token) để xác thực cho ứng dụng của tôi. Và vâng, đó là sự sáng tạo của riêng tôi. - Azngeek
Bạn đã bao giờ tìm ra điều này? Tôi đang thêm tiền thưởng - Adam Waite
Xin chào Adam, thật không may. Bây giờ tôi đã thay đổi cách xác thực hoạt động bằng cách thay đổi Tiêu đề ủy quyền cho mã thông báo thành "x-auth" không phải là tiêu đề chuẩn. - Azngeek
Máy chủ nginx của tôi thậm chí sẽ không chấp nhận 2 Tiêu đề ủy quyền. Nó trả về một 400 Bad request. Ngớ ngẩn. - Rudie
Có gì sai khi sử dụng tiêu đề tùy chỉnh cho mã thông báo API của bạn? Tôi không hiểu tại sao những người ở đây bị "loại bỏ" bằng cách sử dụng HTTP Basic Auth để giữ cho các máy chủ phát triển / dàn dựng của họ tránh xa con mắt tò mò. - Sunil D.


Các câu trả lời:


Hãy thử cái này để đẩy xác thực cơ bản tại url:

curl -i http://username:password@dev.myapp.com/api/users -H "Authorization: Bearer mytoken123"
               ^^^^^^^^^^^^^^^^^^

Nếu ở trên không hoạt động, thì bạn không có gì để làm với nó. Vì vậy, hãy thử các thay thế sau đây.

Bạn có thể chuyển mã thông báo dưới tên khác. Vì bạn đang xử lý ủy quyền từ Ứng dụng của mình. Vì vậy, bạn có thể dễ dàng sử dụng tính linh hoạt này cho mục đích đặc biệt này.

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Application-Authorization: mytoken123"

Lưu ý rằng tôi đã thay đổi tiêu đề thành Application-Authorization. Vì vậy, từ ứng dụng của bạn nắm bắt các mã thông báo dưới tiêu đề đó và xử lý những gì bạn cần làm.

Một điều bạn có thể làm là, để vượt qua token thông qua POST các tham số và lấy giá trị của tham số từ phía Server. Ví dụ: mã thông báo chuyển tiếp với thông số bài đăng curl:

-d "auth-token=mytoken123"

43
2018-03-21 17:04



Xin chào Sabuj, vấn đề không phải là cách bạn vượt qua tên người dùng và mật khẩu nhưng nhiều tiêu đề ủy quyền chỉ không hoạt động. Nhìn vào các thông số kỹ thuật (ietf.org/rfc/rfc2617.txt) tôi có thể thấy rằng điều này sẽ là có thể. Nhưng cũng như đã nói "" Tác nhân người dùng PHẢI chọn sử dụng một trong những thách thức với lược đồ xác thực mạnh nhất mà nó hiểu và yêu cầu thông tin xác thực từ người dùng dựa trên thử thách đó. "Vì vậy, như tôi đã viết 2 ngày trước tôi cần phải vượt qua mã thông báo cho tiêu đề không chuẩn hoàn toàn ổn khi bạn xử lý kiến ​​trúc không chuẩn. - Azngeek
@Azngeek Curl gửi cả hai tiêu đề ủy quyền khi bạn thực hiện tác vụ. Bạn cần phải xử lý nó từ cuối máy chủ của bạn. Chỉ cần chạy lệnh curl của bạn với cả hai tiêu đề -v param. Bạn sẽ thấy rằng nó gửi Authorization: Basic Ym9zY236Ym9zY28=, Authorization: Bearer mytoken123 tại tiêu đề yêu cầu. Từ cuối máy chủ của bạn, nếu bạn kiểm tra, bạn sẽ thấy rằng bạn có tiêu đề Cấp quyền theo cách này Authorization: Basic Ym9zY236Ym9zY28=, Bearer mytoken123 được phân tách bằng dấu phẩy. Vì vậy, tôi mặc dù tôi nên đề nghị bạn thay thế. - Sabuj Hassan


Tiêu chuẩn (https://tools.ietf.org/html/rfc6750) nói rằng bạn có thể sử dụng:

  • Thông số cơ thể được mã hóa biểu mẫu: Ủy quyền: Bearer mytoken123
  • Tham số truy vấn URI: access_token = mytoken123

Vì vậy, nó có thể vượt qua nhiều Bearer Token với URI, nhưng làm điều này là nản lòng (xem phần 5 trong tiêu chuẩn).


26
2017-08-12 07:36





curl --anyauth

Yêu cầu curl tự tìm ra phương thức xác thực và sử dụng   an toàn nhất mà trang web từ xa yêu cầu hỗ trợ. Điều này được thực hiện bởi   đầu tiên thực hiện yêu cầu và kiểm tra các tiêu đề phản hồi, do đó   có thể gây ra thêm một chuyến đi vòng quanh mạng. Điều này được sử dụng   thay vì đặt phương thức xác thực cụ thể, bạn có thể   thực hiện với --basic, --digest, --ntlm và   --đàm phán.


1
2018-03-26 20:30





Nếu bạn đang sử dụng proxy ngược lại như nginx ở giữa, bạn có thể xác định mã thông báo tùy chỉnh, chẳng hạn như X-API-Token.

Trong nginx bạn sẽ viết lại nó cho proxy ngược dòng (api còn lại của bạn) để chỉ là auth:

proxy_set_header Authorization $http_x_api_token;

... trong khi nginx có thể sử dụng tiêu đề Ủy quyền ban đầu để kiểm tra HTTP AU.


1
2018-06-21 14:35





Tôi đã gặp sự cố tương tự - xác thực thiết bị và người dùng tại thiết bị. Tôi đã sử dụng Cookie tiêu đề cùng với một Authorization: Bearer... tiêu đề.


0
2018-04-10 00:43