2012-01-29 33 views
5

Giả sử tôi phát triển một trang mạng xã hội và tôi quyết định rằng tôi muốn cốt lõi của ứng dụng được hoàn toàn REST'ed. Người dùng đăng nhập bằng mật khẩu. Bây giờ, câu hỏi của tôi là mọi yêu cầu yêu cầu mật khẩu và các cặp đăng nhập (giả sử rằng bạn cần phải cung cấp danh tính của bạn) ở cuối URL như www.site.com/index.php?p=pass&l=login? Tôi sẽ có một chút lo lắng về việc yêu cầu điều đó ở mọi yêu cầu. Tôi biết rằng tôi đang thiếu một cái gì đó ... nó không thể được như thế bởi vì bất cứ ai có thể snoop vào các gói dữ liệu và nắm bắt mật khẩu và đăng nhập dễ dàng. Tôi không nghĩ rằng tất cả các yêu cầu được thực hiện trong HTTPS sẽ có ý nghĩa (tôi đọc nó đang đánh thuế các tài nguyên).API REST có yêu cầu mật khẩu và đăng nhập ở mọi yêu cầu không?

Vì vậy, hãy điền vào phần còn thiếu mà tôi cần phải hiểu.

+2

tra * yêu cầu ký *, OAuth và/hoặc các cơ chế xác thực thẻ theo từng vùng. Tôi không có thời gian để viết nó lên như một câu trả lời hoàn chỉnh, nhưng điều này sẽ cung cấp cho bạn một cái gì đó để tìm kiếm. – deceze

+0

cảm ơn - chắc chắn sẽ đọc thêm về chúng – netrox

Trả lời

12

Trước hết, trừ khi bạn biết rằng việc sử dụng SSL quá đắt đối với bạn, hãy sử dụng SSL. Bảo mật xuất hiện trước khi tối ưu hóa hiệu suất.

Bây giờ, về cách chuyển tên người dùng và mật khẩu: thông thường bạn có "mã thông báo truy cập API" hoặc nội dung tương tự. Nó không thực sự là tên người dùng/mật khẩu, nhưng khi ai đó có nó, họ được cấp khả năng tạo yêu cầu API. Đây có thể có giá trị giới hạn hoặc không giới hạn như bạn muốn. Bạn thậm chí có thể làm cho mã thông báo chữ ký - người dùng ký yêu cầu với một số khóa và bạn xác thực chữ ký. Nhưng có, vì mỗi yêu cầu API là độc lập với lần cuối cùng, bạn sẽ phải sử dụng xác thực HTTP cơ bản hoặc tương đương của nó hoặc chuyển mã thông báo API (hoặc thiết bị có chữ ký khác) với mọi yêu cầu.

+1

+1 để bảo mật trước khi thực hiện. Những chu kỳ đã lưu đó sẽ không đáng giá khi bạn dành một tuần để khôi phục thảm họa! – jprofitt

1

Quy tắc theo dõi phiên truyền thống áp dụng cho REST giống như bất kỳ hệ thống nào khác. Đặt cược tốt nhất của bạn là đăng nhập trước, sau đó trả lại cho khách hàng một mã thông báo mà sau đó họ chuyển cho bạn theo mọi yêu cầu (có thể là trong chuỗi truy vấn, cookie hoặc những gì bạn có). Chỉ mục mã thông báo vào một số kho dữ liệu của máy chủ có chứa tất cả thông tin phiên thích hợp - và đặc biệt là thông tin nhận dạng của người dùng, v.v.

6

Thông thường, bạn thực hiện cuộc gọi đến phương thức đăng nhập để tạo mã thông báo có thể được sử dụng lại trong tất cả các yêu cầu tiếp theo.

Lời khuyên của tôi là buộc sử dụng SSL trên mọi yêu cầu, nếu không thể, bạn có thể yêu cầu đăng nhập an toàn và tạo mã thông báo tạm thời cho phiên cụ thể đó (tương tự như ID phiên).

Bạn có thể xem cách OAuth đang được API Flickr sử dụng để cung cấp xác thực trong sơ đồ bên dưới. Trong trường hợp này, một mã thông báo tạm thời được sử dụng để yêu cầu mã thông báo cố định và bí mật mã thông báo.

OAuth Flickr diagram

Trích từ: http://www.flickr.com/services/api/auth.oauth.html#access_token

Các vấn đề liên quan