Bỏ qua nội dung chính
DocsNền tảng mở AIXác thực và hạn chế tốc độ

Xác thực và hạn chế tốc độ

Mang / X-API-Key / yêu cầu ba phương pháp viết, hạn chế tốc độ gói, mã trạng thái HTTP.

Tất cả các điểm kết thúc của nền tảng mở được đồng nhất xác thực thông qua khóa API. Trang này giải thích rõ ràng ba cách viết Tkens, hạn chế tỷ lệ gói và ngữ nghĩa của trả lời lỗi.

Ba Phương pháp ghi xác thực

1. Tác quyền: Bearer (tiểu thức)

bash
curl https://braidrun.com/api/v1/workflows \
  -H "Authorization: Bearer dyk_<id>_<secret>"

Phương pháp ghi chuẩn nhất, được hỗ trợ bởi mọi SDK theo mặc định. Môi trường sản xuất được ưa thích hơn.

2.X-API-Key Header

bash
curl https://braidrun.com/api/v1/workflows \
  -H "X-API-Key: dyk_<id>_<secret>"

Tùy chọn này cho trường hợp ủy nhiệm của một số mạng đóng không thể gửi tới Đầu đề Tác quyền. Tương đương với Bearer.

3. Truy vấn tham số: api key=(chỉ trong trường hợp không thể ghi)

text
https://braidrun.com/api/webhook-trigger/approval/appr-123/approve?api_key=dyk_<id>_<secret>
Dùng tham số truy vấn cẩn thận

Tham số truy vấn sẽ được ghi trong lịch sử trình duyệt, bộ duyệt đầu, bản ghi máy phục vụ HTTP, và bản ghi CDN. Nó chỉ được dùng trong trường hợp cần phải được kích hoạt dưới dạng liên kết get (như email/Slack/Telegram một nhấn chuột), và được dùng với một khoá TTL ngắn. Không bao giờ từ bỏ quyền ưu tiên của Bearer để truy vấn các tham số.

Ưu tiên

  1. Authorization: Bearer dyk_…
  2. X-API-Key: dyk_…
  3. ?api_key=dyk_…

Cố gắng từ trên xuống dưới và ngừng phân tích khi bạn tìm thấy một cái không rỗng.

Giới hạn tốc độ

Mỗi khóa ARI có hai giới hạn trên của "thường là phút" và "một lần", mà được tự động áp dụng theo gói chủ chìa khóa. Mỗi chìa khóa có một chỉ tiêu độc lập và không chia sẻ với các chìa khóa khác trong cùng một tài khoản.

Bảng so sánh gói

Góiphútngày
Free602,000
Pro30050,000
Team1,200500,000
Enterprise6,000Bất kỳ

Ngữ nghĩa cửa sổ

  • cửa sổ phút · Dùng khoảng thời gian giai đoạn là phím, và ranh giới tự động được đặt lại mỗi phút (không phải cửa sổ trượt bắt đầu từ lần gõ đầu)
  • ngày (cửa sổ ngày) · Dùng ngày tháng UTC là phím, tự động đặt lại lúc 00:00 UTC mỗi ngày

Khi đến giới hạn

http
HTTP/1.1 429 Too Many Requests
Retry-After: 38
X-RateLimit-Limit: 60
X-RateLimit-Window: minute
Content-Type: application/json

{
  "error": "Rate limit exceeded",
  "window": "minute",
  "limit": 60,
  "retryAfterSeconds": 38
}

Khách hàng nên:

  • Đọc lại đầu trang sau (số giây), chậm trong khoảng thời gian tương ứng và thử lại
  • X-RateLimit-Window Nói cho bạn biết cửa sổ nào đã bị tấn công ( Phút/ ngày)
  • & Phản đối hiển thị và hoảng loạn; đừng thử lại ngay sau khi nhận được 429
Tên

Cần vượt qua không? Các khóa độc lập được phát hành cho các môi trường khác nhau/sự kết hợp khác nhau, và mỗi phím nhận được một chỉ tiêu đầy đủ. Một người dùng Pro mở 3 key tương đương với tổng khả năng của 900 RPM. Đây cũng là thực hành tốt nhất cho vị trí tai nạn - khi có vấn đề xảy ra, bạn chỉ cần xem xét phím nào có sử dụng bất thường.

Mã Trả lời HTTP

trạng thái mãnghĩa làxử lý chiến thuật
200thành công
202Chấp nhận (khi bắt đầu thực hiện)Phân tích tình trạng với việc thực hiện Id được trả về
400Đã cập nhậtYêu cầu sửa chữa, đừng thử lại
401Token mất tích/wrong định dạng/revoked/epryed/unmenedKiểm tra lại Token và phạm vi; đừng thử lại
403Đã cập nhậtLiên lạc với quản trị tài khoản của bạn; đừng thử lại
404Tài nguyên không tồn tại hoặc không có tầm nhìnKiểm tra mã số/ kính; đừng thử lại
409Xung đột Trạng thái (v. d. sự chấp thuận đã được quyết định)Hỏi lại tình trạng hiện thời
429Giới hạn tốc độThử lại sau khi tuân theo lệnh thử lại sau
500/502/503Lỗi máy phục vụTự động lùi lại 3-5 lần
Tại sao 401 không phân biệt giữa lý do

Mất điện, quá hạn, thu hồi và không đủ phạm vi tất cả đều trở về một cách đồng nhất, mà không phơi bày lý do thất bại cụ thể - điều này tránh những kẻ tấn công sử dụng thử và sai để phát hiện phím nào tồn tại/ phạm vi nào được bật. Lý do hoàn toàn bị thất bại (chiến trường) vẫn còn trong bản ghi kiểm tra và có thể được quản trị kiểm tra.