OAuth device flow cho CLI dữ liệu: polling đúng interval
OAuth device flow cho CLI dữ liệu là cách để một công cụ dòng lệnh xin quyền đọc API thay người dùng mà không cần nhận mật khẩu. CLI hiện một mã ngắn, người dùng mở trình duyệt trên máy khác để đăng nhập và đồng ý, còn CLI hỏi máy chủ định kỳ cho tới khi có token. ProxyVN dựng một máy chủ ủy quyền lab theo RFC 8628, chạy năm kịch bản polling và ghi lại từng lần hỏi, kể cả ca người dùng đã đồng ý mà CLI vẫn không lấy được token.
OAuth device flow cho CLI dữ liệu: mục tiêu và phạm vi không lặp
Phần này chốt bài toán, đầu ra và những thứ bài không làm.
Bài toán cần giải
Một nhóm dữ liệu có CLI tải bộ dữ liệu từ API của đối tác. Trước đây, người dùng dán API key vào tệp cấu hình. Đối tác chuyển sang OAuth và yêu cầu mỗi người tự đăng nhập. CLI chạy trên máy chủ không có trình duyệt, nên luồng chuyển hướng thông thường không dùng được. Device flow sinh ra cho đúng tình huống này.
Đầu ra nghiệm thu
Đầu ra là một sequence đầy đủ: xin device code, hiện user code, poll, nhận token. Kèm theo là các ca slow_down, expired_token và access_denied với dấu thời gian từng lần hỏi, ghi từ cả phía client lẫn phía máy chủ. Thêm phép kiểm token không lọt ra log.
Ranh giới với bài PKCE
Bài PKCE trong cụm này nói về luồng authorization code, nơi trình duyệt chuyển hướng về ứng dụng và code verifier bảo vệ bước đổi code. Device flow không có chuyển hướng. Nó thay bằng polling và mã người dùng nhập tay. Hai bài giải hai bài toán khác nhau.
Proxy không thay sự đồng ý
Proxy chỉ đổi đường đi của request. Nó không đăng nhập thay người dùng, không bấm đồng ý, không làm token có thêm quyền hay thêm hạn mức. Bài không có cách nào dùng proxy để bỏ qua bước người dùng xác nhận, và không nên có.
Giới hạn của lab
Nói rõ ngay. Lab không dùng nhà cung cấp OAuth thật. ProxyVN viết một máy chủ ủy quyền nhỏ theo RFC 8628 trên cổng 9485. Bước người dùng đăng nhập và bấm đồng ý được thay bằng một request tới trang xác nhận của lab. Client CLI viết bằng requests 2.34.2.
Thứ gì theo RFC, thứ gì do lab đặt
Tên tham số, mã lỗi, quy tắc tăng 5 giây khi slow_down, giá trị mặc định 5 giây lấy từ RFC. Cách máy chủ quyết định thế nào là hỏi quá nhanh do ProxyVN đặt. Interval 1 giây và thời hạn 5 tới 12 giây là số rút ngắn để lab chạy nhanh, máy chủ thật thường dài hơn nhiều.
Ai nên đọc bài này
Người viết CLI hoặc script cần token OAuth của người dùng. Người từng thấy CLI báo hết hạn dù đã bấm đồng ý. Người cần giải thích cho đối tác vì sao CLI không gửi quá nhiều request tới token endpoint.
OAuth device flow cho CLI dữ liệu: thiết kế polling đúng interval
Phần này tóm tắt các điểm chính của RFC 8628.
Hai endpoint
RFC 8628 định nghĩa endpoint mới là device authorization, tách khỏi authorization endpoint của RFC 6749. Client trên thiết bị nói chuyện thẳng với máy chủ, không qua trình duyệt. Người dùng ủy quyền trên một thiết bị khác. Sau đó client hỏi token endpoint quen thuộc.
Request xin mã
Client gửi POST dạng form tới device authorization endpoint với client_id và scope. RFC yêu cầu mọi request từ thiết bị dùng TLS. RFC cũng khuyên chỉ bắt đầu luồng khi người dùng yêu cầu, không tự chạy lúc ứng dụng khởi động, để tránh request vô ích.
Phản hồi xin mã
Máy chủ trả JSON với mã 200 gồm device_code, user_code, verification_uri, expires_in là bắt buộc. Verification_uri_complete và interval là tùy chọn. RFC nêu nếu không có interval, client phải dùng 5 giây.
Trường |
Bắt buộc |
Dùng làm gì |
|---|---|---|
device_code |
Có |
Client gửi khi poll, không hiện cho người dùng |
user_code |
Có |
Người dùng nhập trên trình duyệt |
verification_uri |
Có |
Địa chỉ người dùng mở |
verification_uri_complete |
Không |
Địa chỉ có sẵn mã, dùng cho mã QR |
expires_in |
Có |
Thời hạn của cả hai mã |
interval |
Không |
Khoảng chờ tối thiểu giữa hai lần poll |
Poll token endpoint
Client gửi POST tới token endpoint với grant_type là chuỗi urn:ietf:params:oauth:grant-type:device_code, kèm device_code và client_id. Máy chủ trả token khi người dùng đã đồng ý, hoặc trả một mã lỗi.
authorization_pending
RFC nêu mã này nghĩa là người dùng chưa xong bước xác nhận. Client nên gửi lại request. Trước mỗi request mới, client phải chờ ít nhất interval giây, cộng phần tăng do slow_down nếu có.
slow_down
RFC nêu đây là biến thể của authorization_pending: vẫn đang chờ, vẫn tiếp tục poll, nhưng interval phải tăng thêm 5 giây cho request này và mọi request sau. Từ phải ở đây là bắt buộc, không phải khuyến nghị.
access_denied và expired_token
Access_denied nghĩa là yêu cầu bị từ chối. Expired_token nghĩa là device_code đã hết hạn, phiên ủy quyền kết thúc. RFC nêu client có thể bắt đầu phiên mới nhưng nên chờ người dùng yêu cầu, không tự khởi động lại.
Mã lỗi khác thì dừng
RFC nêu authorization_pending và slow_down là hai mã đặc biệt, cho biết phải tiếp tục poll. Nếu nhận bất kỳ mã lỗi nào khác, client phải dừng poll và nên phản hồi phù hợp, ví dụ hiện lỗi cho người dùng. Đây là điều kiện dừng quan trọng nhất của CLI.
OAuth device flow cho CLI dữ liệu: xin device_code và hiện user_code cùng verification URI
Phần này dựng máy chủ lab, client và bước đầu tiên.
Máy chủ lab
Máy chủ lab có ba đường dẫn: device_authorization, token và device. Đường dẫn device đóng vai trang người dùng nhập mã rồi bấm đồng ý hoặc từ chối. Máy chủ ghi log mỗi lần poll với thời điểm, user code, kết quả và khoảng cách so với lần trước.
Sinh mã
Device_code là chuỗi ngẫu nhiên dài, client giữ bí mật. User_code ngắn, gồm hai nhóm bốn chữ cái nối bằng gạch ngang, chỉ dùng phụ âm để tránh nhầm và tránh ghép thành từ có nghĩa. Máy chủ lab chấp nhận user code viết thường, vì người dùng hay gõ thường.
Client xin mã
r = requests.post(BASE + "/device_authorization",
data={"client_id": "cli-du-lieu", "scope": "read:dataset"}).json()
print(f"Mo {r['verification_uri']} va nhap ma {r['user_code']}")
interval = r.get("interval", 5)Dòng cuối áp quy tắc mặc định 5 giây của RFC khi máy chủ không gửi interval.
Hiện cho người dùng
CLI in ra địa chỉ và mã, kèm thời hạn. Lab in dòng sau.
[0.0] Mo http://127.0.0.1:9485/device va nhap ma ZXDC-ZJCL (het han sau 12s)Với máy chủ thật, CLI có thể in thêm mã QR từ verification_uri_complete để người dùng quét bằng điện thoại.
Kiểm phản hồi trước khi dùng
CLI nên kiểm phản hồi có đủ bốn trường bắt buộc trước khi in. Thiếu verification_uri hay user_code là dấu hiệu gọi sai endpoint hoặc client_id sai. Máy chủ lab trả invalid_client khi client_id không đúng. Báo lỗi ngay ở bước này dễ hiểu hơn để người dùng mở một địa chỉ rỗng.
Ghi expires_in theo đồng hồ của client
Ngay khi nhận phản hồi, CLI tính mốc hết hạn bằng thời điểm hiện tại cộng expires_in. Mốc này dùng cho điều kiện dừng phía client. Tính một lần ở đầu, không tính lại mỗi lần poll, để thời gian chờ không bị kéo dài dần.
Không in device_code
Device_code là thứ đổi được ra token. In nó ra màn hình hay ghi vào log là để lộ một nửa luồng. CLI chỉ in user_code và địa chỉ. Nếu cần gỡ lỗi, in vài ký tự đầu của device_code là đủ để phân biệt các phiên.
Thông báo dễ hiểu
Người dùng CLI dữ liệu thường không quen OAuth. Thông báo nên nói rõ ba việc: mở địa chỉ nào, nhập mã nào, trong bao lâu. Thêm một câu cho biết CLI đang chờ và có thể bấm Ctrl C để hủy. Thông báo rõ giảm số phiên hết hạn vì người dùng không biết phải làm gì.
Khi nào bắt đầu luồng
Theo khuyến nghị của RFC, CLI chỉ bắt đầu device flow khi người dùng gõ lệnh đăng nhập, hoặc khi lệnh tải dữ liệu không có token hợp lệ. Không tự bắt đầu mỗi lần CLI chạy. Một cron job chạy CLI mỗi giờ mà tự bắt đầu device flow sẽ sinh hàng loạt phiên không ai xác nhận.
OAuth device flow cho CLI dữ liệu: polling đúng interval trong khi chờ user consent
Phần này là kịch bản bình thường và vòng lặp poll.
Vòng lặp poll
Vòng lặp chờ interval, gửi request token, xử lý kết quả. Chờ trước khi gửi, kể cả lần đầu, vì người dùng chưa kịp làm gì ngay khi mã vừa hiện.
while True:
time.sleep(interval)
tr = requests.post(BASE + "/token", data={
"grant_type": "urn:ietf:params:oauth:grant-type:device_code",
"device_code": r["device_code"], "client_id": "cli-du-lieu"})
body = tr.json()
if tr.status_code == 200: return body
e = body["error"]
if e == "authorization_pending": continue
if e == "slow_down": interval += 5; continue
return bodyNhánh cuối dừng với mọi mã lỗi khác, đúng yêu cầu của RFC.
Kịch bản A: bình thường
Ba lần poll
Interval 1 giây. Người dùng bấm đồng ý ở giây 2,5. Client poll ba lần.
client: [(1.01, 'authorization_pending', 1), (2.01, 'authorization_pending', 1), (3.01, 'TOKEN', 1)]
server: [(1.01, 'authorization_pending', None), (2.01, 'authorization_pending', 1.0), (3.01, 'TOKEN', 1.0)]Cột cuối của log máy chủ là khoảng cách giữa hai lần poll, đúng 1 giây. Lần thứ ba nhận token.
Sequence đầy đủ
Bảng dưới là sequence của kịch bản A, ghép từ log hai phía.
Thời điểm |
Bên |
Hành động |
Kết quả |
|---|---|---|---|
0,0 |
CLI |
Xin mã |
device_code, user_code ZXDC-ZJCL |
0,0 |
CLI |
In địa chỉ và mã |
|
1,01 |
CLI |
Poll lần 1 |
authorization_pending |
2,01 |
CLI |
Poll lần 2 |
authorization_pending |
2,5 |
Người dùng |
Nhập mã, đồng ý |
|
3,01 |
CLI |
Poll lần 3 |
Token Bearer |
Token dùng một lần đổi
Sau khi trả token, máy chủ lab đánh dấu phiên đã dùng. Poll lại cùng device_code nhận invalid_grant. Đây là cách lab chặn việc một device_code bị lộ được dùng lại. RFC để chi tiết này cho máy chủ, nên máy chủ thật có thể khác.
Thời gian chờ thực tế
Với máy chủ thật, interval thường 5 giây và thời hạn vài phút. Người dùng mất từ mười giây tới vài phút để mở trình duyệt, đăng nhập, nhập mã. CLI sẽ poll vài chục lần. Con số này là bình thường và là lý do quy tắc interval tồn tại.
Đồng hồ của client
Client đo interval bằng đồng hồ của chính nó. Nếu máy bị treo hay ngủ giữa chừng, lần poll tiếp theo có thể muộn, không sao. Điều client không được làm là gửi sớm hơn interval. Dùng sleep sau mỗi request như lab là cách đơn giản và đủ.
OAuth device flow cho CLI dữ liệu: xử lý authorization_pending, slow_down và expired_token
Phần này đi qua các ca lỗi, phần quan trọng nhất của bài.
Kịch bản B: poll nhanh hơn interval
Poll nhanh bị phạt
Client cấu hình sai, poll mỗi 0,4 giây thay vì 1 giây. Nó xử lý slow_down đúng RFC, tăng 5 giây mỗi lần. Người dùng đồng ý ở giây 3.
client: [(0.41, 'authorization_pending', 0.4), (0.81, 'slow_down', 0.4),
(6.21, 'slow_down', 5.4), (16.61, 'expired_token', 10.4)]Kết quả: hết hạn, không có token, dù người dùng đã đồng ý.
Vì sao lại hết hạn
Lần slow_down đầu, client tăng từ 0,4 lên 5,4 giây. Máy chủ lab cũng tăng ngưỡng của phiên từ 1 lên 6 giây. Lần poll sau cách 5,4 giây, vẫn dưới 6, lại slow_down. Client lên 10,4 giây, và lần poll tiếp rơi vào giây 16,6, sau thời hạn 12 giây.
Bài học từ kịch bản B
Client không bao giờ được poll nhanh hơn interval máy chủ gửi. Mỗi slow_down cộng thêm 5 giây vào cả hai phía, và client bắt đầu thấp hơn ngưỡng sẽ luôn đuổi theo. Cách máy chủ lab nâng ngưỡng là do ProxyVN đặt, nhưng máy chủ thật có quyền làm tương tự.
Người dùng không biết chuyện gì
Trong kịch bản B, người dùng thấy trang báo đồng ý thành công. CLI lại báo hết hạn. Người dùng sẽ nghĩ dịch vụ lỗi và gửi phiếu hỗ trợ. Một dòng log ghi rõ đã nhận slow_down hai lần giúp người hỗ trợ hiểu ngay lỗi nằm ở CLI.
Kịch bản C: bỏ qua slow_down
Một client tệ hơn: poll 0,4 giây và không tăng interval khi nhận slow_down. Trong 8 giây, nó gửi 20 request, 18 lần nhận slow_down, rồi hết hạn.
== C bo qua slow_down: ket qua expired_token | so lan poll 20Với máy chủ thật, client kiểu này có thể bị khóa client_id. Hai mươi request cho một người dùng, nhân với số người dùng, là tải đáng kể lên token endpoint.
Kịch bản D: người dùng không làm gì
Thời hạn 5 giây, interval 1 giây, không ai xác nhận. Client poll bốn lần nhận authorization_pending, lần năm nhận expired_token và dừng.
client: [(1.0, 'authorization_pending', 1), ..., (4.01, 'authorization_pending', 1), (5.02, 'expired_token', 1)]Client dừng đúng lúc, không tự khởi động phiên mới.
Kịch bản E: người dùng từ chối
Người dùng bấm từ chối ở giây 1,5. Lần poll thứ hai nhận access_denied, client dừng ngay.
client: [(1.0, 'authorization_pending', 1), (2.01, 'access_denied', 1)]Không thử lại, không hỏi lại. Từ chối là quyết định của người dùng.
Bảng tổng hợp
Năm kịch bản
Kịch bản |
Cách poll |
Người dùng |
Số lần poll |
Kết quả |
|---|---|---|---|---|
A |
Đúng interval |
Đồng ý giây 2,5 |
3 |
Token |
B |
0,4 giây, xử lý slow_down |
Đồng ý giây 3 |
4 |
expired_token |
C |
0,4 giây, bỏ qua slow_down |
Không |
20 |
expired_token |
D |
Đúng interval |
Không |
5 |
expired_token |
E |
Đúng interval |
Từ chối giây 1,5 |
2 |
access_denied |
Hết hạn rồi thì sao
Theo RFC, client có thể bắt đầu phiên mới nhưng nên chờ người dùng yêu cầu. CLI in thông báo mã đã hết hạn và gợi ý chạy lại lệnh đăng nhập. Không tự vòng lại, vì nếu người dùng đã rời máy, CLI sẽ sinh phiên mới mãi.
Lỗi mạng khi poll
Một lần poll bị lỗi mạng không phải mã lỗi OAuth. Client có thể thử lại lần sau theo interval, miễn là chưa quá thời hạn. Nhưng không được thử lại ngay lập tức, vì đó cũng là poll nhanh hơn interval. Lab không thử ca này.
OAuth device flow cho CLI dữ liệu: giữ token ngoài log và chốt điều kiện dừng
Phần này nói về token sau khi nhận và các điều kiện dừng của CLI.
Che token trong log
Che token trong log
CLI ghi log phản hồi token để gỡ lỗi, nhưng che access_token và refresh_token bằng biểu thức chính quy. Lab kiểm log sau kịch bản A.
token response {"access_token": "at_***", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "rt_***", "scope": "read:dataset"}
token trong log goc co lo khong: FalseHàm che phụ thuộc định dạng token của máy chủ lab. Với máy chủ thật, che theo tên trường an toàn hơn theo tiền tố.
Đừng log cả request
Thư viện HTTP ở mức gỡ lỗi có thể in cả thân request và phản hồi. Bật mức gỡ lỗi của urllib3 hay requests khi đang có token là cách nhanh nhất để token nằm trong tệp log. Chỉ bật khi cần, và chỉ trên máy cá nhân.
Lưu token ở đâu
Access token và refresh token nên lưu vào kho bí mật của hệ điều hành, hoặc tệp chỉ người dùng đọc được. Không lưu trong tệp cấu hình chung của dự án, không đẩy lên kho mã. Lab giữ token trong bộ nhớ và không ghi ra đĩa.
Dùng refresh token
Khi access token hết hạn, CLI dùng refresh token để lấy token mới, không cần người dùng làm lại device flow. Device flow chỉ chạy lại khi refresh token hết hạn hoặc bị thu hồi. Lab không thử bước refresh.
Scope tối thiểu
CLI dữ liệu chỉ cần quyền đọc bộ dữ liệu. Xin scope read:dataset như lab, không xin quyền ghi hay quản trị. Người dùng thấy scope trên trang xác nhận, scope gọn giúp họ yên tâm đồng ý.
Điều kiện dừng của CLI
CLI dừng poll khi có một trong các điều sau: nhận token, nhận mã lỗi khác authorization_pending và slow_down, quá thời hạn expires_in theo đồng hồ của client, hoặc người dùng hủy. Mã lab dừng theo mã lỗi. Thêm kiểm thời hạn phía client giúp CLI không chờ mãi nếu máy chủ không trả lời.
deadline = time.time() + r["expires_in"]
if time.time() > deadline:
raise SystemExit("Ma da het han, chay lai lenh dang nhap")Hủy bằng Ctrl C
Người dùng bấm Ctrl C khi đang chờ thì CLI thoát gọn, không in dấu vết ngăn xếp dài. Device_code còn hạn trên máy chủ nhưng không ai dùng nữa, sẽ tự hết hạn. Đây là hành vi chấp nhận được.
Chạy không người
CLI chạy trong cron hay CI không nên dùng device flow, vì không có ai xác nhận. Với tác vụ không người, dùng luồng dành cho máy với máy, như client credentials, nếu đối tác hỗ trợ. Device flow dành cho người ngồi trước một thiết bị không có trình duyệt tiện dùng.
OAuth device flow cho CLI dữ liệu: trải nghiệm người dùng và vận hành
Phần này nói về những chi tiết làm device flow dễ dùng hoặc khó dùng, ngoài phần giao thức.
Mã người dùng dễ gõ
RFC để máy chủ tự chọn định dạng user code. Mã ngắn, chia nhóm, không có ký tự dễ nhầm như số 0 và chữ O giúp người dùng gõ đúng lần đầu. Máy chủ lab dùng tám chữ cái phụ âm chia hai nhóm. Mỗi lần gõ sai, người dùng mất thêm thời gian, và CLI tiếp tục poll trong lúc đó.
Hiện thời gian còn lại
CLI có thể in thời gian còn lại mỗi khi poll, ví dụ còn 4 phút. Người dùng biết còn kịp hay phải làm lại. Không cần in mỗi lần poll, vài chục giây một lần là đủ. Lab không làm phần này vì thời hạn quá ngắn.
Thông báo khi thành công
Khi nhận token, CLI in một dòng xác nhận kèm tên tài khoản nếu API cho phép lấy. Người dùng biết đã đăng nhập đúng tài khoản. Nhầm tài khoản là lỗi phổ biến khi trình duyệt đang đăng nhập sẵn một tài khoản khác.
Phân biệt lỗi với người dùng
Mỗi kết quả dừng cần một thông báo riêng. Hết hạn thì gợi ý chạy lại. Từ chối thì nói rõ đã bị từ chối trên trình duyệt. Lỗi khác thì in mã lỗi và gợi ý liên hệ người quản trị. Gộp mọi thứ thành đăng nhập thất bại làm người dùng không biết nên làm gì.
Ghi lại số lần slow_down
Mỗi lần nhận slow_down là một dấu hiệu CLI đang poll quá nhanh. Ghi đếm vào log, và nếu đếm lớn hơn không ở phiên bình thường, có lỗi cấu hình. Trong kịch bản B, log sẽ cho thấy hai lần slow_down trước khi hết hạn, đủ để chẩn đoán ngay.
Cấu hình interval không được thấp hơn máy chủ
CLI có thể cho người dùng đặt khoảng chờ tối thiểu, nhưng giá trị dùng thực tế phải là số lớn hơn giữa cấu hình và interval của máy chủ. Lab cố tình cho phép giá trị thấp hơn để tái lập lỗi. Mã thật nên chặn điều này ngay khi đọc cấu hình.
Nhiều người dùng, nhiều phiên
Mỗi người dùng chạy CLI tạo một phiên riêng với device_code riêng. Máy chủ theo dõi interval theo từng phiên. Hai người trên cùng một máy không ảnh hưởng nhau. Lab chỉ có một phiên mỗi lúc, chưa thử nhiều phiên song song.
Tài liệu cho người dùng
Một đoạn hướng dẫn ngắn trong tài liệu CLI: chạy lệnh đăng nhập, mở địa chỉ, nhập mã, chờ thông báo. Thêm một câu: nếu thấy hết hạn, chạy lại lệnh, đừng chạy nhiều lần cùng lúc. Hướng dẫn ngắn giảm phần lớn câu hỏi hỗ trợ.
Kiểm thử tự động
Máy chủ lab có thể dùng làm test tự động cho CLI. Test chạy năm kịch bản, kiểm số lần poll và kết quả. Interval rút ngắn giúp test chạy trong khoảng một phút. Mỗi khi sửa vòng lặp poll, chạy lại để chắc không làm hỏng quy tắc slow_down.
OAuth device flow cho CLI dữ liệu: đầu ra nghiệm thu và phần chưa chạy
Phần này gom tiêu chí đạt, tệp đầu ra và những gì còn phải kiểm.
Danh sách kiểm tra
CLI đạt khi mọi dòng dưới đây đúng.
- Chỉ bắt đầu device flow khi người dùng yêu cầu.
- Dùng interval máy chủ gửi, mặc định 5 giây nếu không có.
- Chờ trước mỗi lần poll, kể cả lần đầu.
- Tăng interval thêm 5 giây mỗi lần nhận slow_down.
- Dừng với mọi mã lỗi khác authorization_pending và slow_down.
- Kiểm thời hạn expires_in phía client.
- Không in device_code, che token trong log.
- Xin scope tối thiểu, lưu token ở nơi an toàn.
Tệp đầu ra của lab
Lab có run.py chứa máy chủ ủy quyền, client và năm kịch bản. Output in cả log client lẫn log máy chủ với dấu thời gian. Chạy lại mất khoảng một phút, mỗi lần sinh mã mới.
Những gì lab chưa chạy
Chưa chạy với nhà cung cấp OAuth thật, chưa có TLS, chưa có trang đăng nhập thật, chưa thử refresh token, lỗi mạng khi poll, nhiều người dùng cùng lúc. Cách máy chủ nâng ngưỡng khi slow_down là do lab đặt. Interval và thời hạn là số rút ngắn.
Kiểm lại với nhà cung cấp thật
Đọc tài liệu device flow của nhà cung cấp, ghi lại interval, thời hạn và cách họ xử lý poll nhanh. Chạy kịch bản A với tài khoản thử. Không chạy kịch bản C với máy chủ thật, vì đó là cố tình gửi request quá nhanh.
Proxy ở đâu trong luồng này
Nếu mạng của anh em bắt buộc đi qua proxy, request xin mã và request poll đều đi qua proxy như mọi request HTTP khác. Proxy không đổi gì trong luồng: cùng mã, cùng interval, cùng token. Với API được phép truy cập, khi cần IP Việt Nam ổn định, anh em có thể mua proxy tại trang chủ ProxyVN. Vai trò proxy có ở bài Web Scraping proxy là gì, cách ghi chuỗi proxy ở bài định dạng proxy.
Proxy không tăng hạn mức
Hạn mức API gắn với token và client_id, không gắn với IP. Đổi proxy không cho thêm request. Dùng nhiều IP để poll nhanh hơn interval vẫn là poll nhanh hơn interval, vì máy chủ theo dõi theo device_code. Lab kiểm theo device_code, không theo IP.
OAuth device flow cho CLI dữ liệu: câu hỏi thường gặp
Các câu dưới đây gom những điểm anh em hay hỏi.
Interval mặc định là bao nhiêu?
5 giây nếu máy chủ không gửi trường interval. RFC 8628 ghi rõ client phải dùng giá trị này.
Nhận slow_down thì làm gì?
Tăng interval thêm 5 giây cho request này và mọi request sau, rồi tiếp tục poll. Lab thấy client bắt đầu dưới ngưỡng sẽ bị slow_down liên tiếp.
Vì sao đã đồng ý mà CLI vẫn báo hết hạn?
Thường vì CLI poll quá nhanh, bị slow_down, interval tăng tới mức lần poll sau rơi vào sau thời hạn. Kịch bản B của lab tái lập đúng chuyện này.
Hết hạn có nên tự bắt đầu lại không?
Không nên. RFC khuyên chờ người dùng yêu cầu. CLI in thông báo và để người dùng chạy lại lệnh.
Device flow có dùng cho cron được không?
Không hợp. Không ai ngồi xác nhận. Dùng luồng máy với máy nếu đối tác hỗ trợ.
Có cần TLS khi chạy nội bộ không?
RFC yêu cầu mọi request từ thiết bị dùng TLS. Lab chạy HTTP thường trên máy cục bộ chỉ để quan sát. Với máy chủ thật, kể cả trong mạng nội bộ, device_code và token đi trên đường truyền, nên phải có TLS.
User code có phân biệt hoa thường không?
RFC để máy chủ quyết định. Máy chủ lab chấp nhận chữ thường và đổi sang chữ hoa trước khi so. Nhiều máy chủ làm tương tự để người dùng đỡ gõ sai.
Một device_code dùng được mấy lần?
Trong lab, một lần. Sau khi trả token, phiên được đánh dấu đã dùng và poll lại nhận invalid_grant. Máy chủ thật có thể khác, nhưng client không nên dựa vào việc dùng lại.
Nên đặt thời hạn chờ phía client bao lâu?
Bằng expires_in máy chủ gửi. Đừng đặt dài hơn, vì sau thời hạn máy chủ chỉ trả expired_token. Đừng đặt ngắn hơn quá nhiều, vì người dùng cần thời gian đăng nhập.
Bài có chạy với nhà cung cấp OAuth thật không?
Không. Máy chủ ủy quyền là bản lab theo RFC 8628. Kết quả chứng minh logic poll của client, không chứng minh hành vi của một nhà cung cấp cụ thể.
OAuth device flow cho CLI dữ liệu và những điều cần nhớ
OAuth device flow cho CLI dữ liệu chỉ chạy ổn khi client poll đúng interval máy chủ gửi, tăng 5 giây mỗi lần slow_down và dừng với mọi mã lỗi khác. Hãy chờ trước mỗi lần poll, kiểm thời hạn phía client, che token trong log. Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam khuyên anh em thử OAuth device flow cho CLI dữ liệu với tài khoản thử trước.
