Xác thực mã thông báo mang và HTTP cơ bản

Tôi hiện đang phát triển REST-API được bảo vệ HTTP-Basic cho môi trường phát triển. Vì xác thực thực được thực hiện thông qua 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 Xác thực HTTP 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 các IP động, đây không phải là một giải pháp tốt. Vậy tôi có thiếu gì không?

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 cách thay thế sau.

Bạn có thể chuyển mã thông báo dưới một 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 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, bắt 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 khác bạn có thể làm là chuyển tokenqua các POSTtham số và lấy giá trị của tham số từ phía Server. Ví dụ: truyền mã thông báo với tham số curl post:

-d "auth-token=mytoken123"

Standard ( https://tools.ietf.org/html/rfc6750 ) cho biết 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, có thể vượt qua nhiều Bearer Token với URI, nhưng làm điều này không được khuyến khích (xem phần 5 trong tiêu chuẩn).

Nếu bạn đang sử dụng proxy ngược 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ó để proxy ngược dòng (api còn lại của bạn) chỉ là xác thực:

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 AUth.

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

curl --anyauth

Yêu cầu curl tự tìm ra phương pháp xác thực và sử dụng phương pháp bảo mật nhất mà trang web từ xa tuyên bố sẽ hỗ trợ. Điều này được thực hiện trước tiên bằng cách thực hiện một yêu cầu và kiểm tra các tiêu đề phản hồi, do đó có thể tạo ra một mạng bổ sung khứ hồi. Điều này được sử dụng thay vì đặt một phương thức xác thực cụ thể, mà bạn có thể thực hiện với --basic, --digest, --ntlm và --negotiate.

Có một giải pháp khác để kiểm tra API trên máy chủ phát triển.

• Chỉ đặt HTTP Basic Authenticationcho các tuyến web
• Để tất cả các tuyến API không bị xác thực

Cấu hình máy chủ web cho nginxvà Laravelsẽ như thế này:

    location /api {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location / {
        try_files $uri $uri/ /index.php?$query_string;

        auth_basic "Enter password";
        auth_basic_user_file /path/to/.htpasswd;
    }

Authorization: Bearer sẽ thực hiện công việc bảo vệ máy chủ phát triển trước trình thu thập dữ liệu web và những người truy cập không mong muốn khác.

Với nginx, bạn có thể gửi cả hai mã thông báo như thế này (mặc dù nó trái với tiêu chuẩn):

Authorization: Basic basic-token,Bearer bearer-token

Điều này hoạt động miễn là mã thông báo cơ bản là đầu tiên - nginx chuyển tiếp thành công nó đến máy chủ ứng dụng.

Và sau đó bạn cần đảm bảo rằng ứng dụng của bạn có thể trích xuất Bearer từ chuỗi trên một cách chính xác.