Tôi đã tạo một số Dịch vụ web sản xuất/sử dụng dữ liệu JSON và tôi đã bảo vệ chúng bằng cách sử dụng Mã thông báo OAuth2 và Bearer, hoạt động tốt.Bảo vệ tài nguyên hình ảnh bằng mã thông báo OAuth2 Bearer
Tuy nhiên, bây giờ tôi cần phải xây dựng một Dịch vụ web tương tự tạo hình ảnh thay vì JSON (dữ liệu JPEG/PNG). Để nhất quán, tôi cũng muốn bảo vệ dịch vụ bằng mã OAuth2/Bearer, nhưng làm như vậy sẽ làm cho dịch vụ trở nên khó khăn hơn trong việc sử dụng các ứng dụng dựa trên trình duyệt muốn hiển thị dữ liệu hình ảnh bằng cách sử dụng thẻ <img>, vì <img> sẽ không gửi tiêu đề HTTP cần thiết Authorization: Bearer ...bearer-token....
tôi có thể thấy hai cách vòng này:
khách hàngTrình duyệt dựa trên các dịch vụ sẽ sử dụng XHR level2 và các đề án URL Blob và Blob từ HTML5 để lấy dữ liệu hình ảnh như một Blob, sử dụng Blob Lược đồ URL để tạo URL cho Blob và sau đó tự động tạo thẻ img đề cập đến Blob URl. Rất nhiều công việc chỉ để hiển thị một hình ảnh!
Sửa đổi cơ sở hạ tầng OAuth2 để tạo cookie Http ngoài Mã thông báo người gửi. Sửa đổi dịch vụ Authorirzation để chấp nhận EITHER the Authorization: Bearer ... Tiêu đề OAuth2 HOẶC cookie làm bằng chứng nhận dạng. Cookie có cùng tuổi thọ như mã thông báo mang, httpOnly, vv .. Trình duyệt dựa trên khách hàng chỉ có thể dựa vào hỗ trợ cookie của trình duyệt để có quyền truy cập vào dịch vụ, có thể thu thập dữ liệu hình ảnh qua <img> thẻ như bình thường. Dễ sử dụng cho khách hàng trình duyệt, nhưng không chuẩn. Hồ sơ rủi ro bảo mật có vẻ giống nhau đối với mã thông báo hoặc cookie của người mang.
Tôi có xem xét bất kỳ sự cố bảo mật nào với phương pháp sau không?
Có phương pháp thay thế nào để bảo vệ tài nguyên hình ảnh/phương tiện với OAuth2 không?
Tôi đã quên/giảm cơ chế tham số truy vấn, rõ ràng đây là trường hợp sử dụng được thiết kế, cảm ơn. – cdivilly
Điều này có nghĩa là, ở phía máy chủ (có thể nằm trong bộ lọc), trước hết chúng ta cần kiểm tra tiêu đề 'Authorization'; nếu nó rỗng, hãy kiểm tra 'request.getParameter (" access_token ")'? –