Cách thiết kế API RESTful để kiểm tra thông tin đăng nhập của người dùng?

Question

Tôi đang thiết kế API cho ứng dụng dành cho thiết bị di động và tôi hy vọng giữ cho nó yên tĩnh.
API được ủy quyền sử dụng Xác thực HTTP cơ bản, tuy nhiên, khi người dùng mở ứng dụng lần đầu tiên, trước tiên, anh cần đăng nhập, vì vậy tôi cần thiết kế API để kiểm tra thông tin xác thực của người dùng. mật khẩu, trả về thành công hoặc thất bại cho phù hợp.
vấn đề là url nên được giữ gìn? Tôi không nghĩ/đăng nhập là tốt nhất.

Answer 1

Cách tiếp cận tốt là thực hiện yêu cầu GET cho thông tin tài khoản/hồ sơ của người dùng hiện tại. và đưa nó trở lại tên người dùng, cài đặt, url hình đại diện, v.v. me thường được sử dụng làm định danh viết tắt của người dùng xác thực.

GET https://api.example.com/profiles/me 
HTTP/1.1 200 OK 
{ 
    "username": "bob", 
    "id": "xyz", 
    "created_at": 123, 
    "image_url": "https://example.com/bob.png" 
} 

Answer 2

Từ wikipedia:

Các giao tiếp client-server là tiếp tục bị hạn chế bởi không có khách hàng bối cảnh được lưu trữ trên máy chủ giữa các yêu cầu. Mỗi yêu cầu từ bất kỳ khách hàng nào đều chứa tất cả thông tin cần thiết để phục vụ yêu cầu và bất kỳ trạng thái phiên nào được giữ trong ứng dụng khách.

Bởi vì các cửa hàng máy chủ không có trạng thái phiên từ khách hàng, API của bạn không nên tiếp xúc với bất kỳ khả năng đăng nhập/đăng xuất: Trong mỗi yêu cầu bạn nên gửi thông tin người dùng, và máy chủ nên xác nhận chúng mỗi lần.

Kiểm tra this discussion in SO, nó claryfies khái niệm này.

Answer 3

Tôi đồng ý với Carlos - trong API bình thường, không có phiên để bạn không thể xác thực một lần và sau đó sử dụng lại phiên, bạn thực sự cần phải vượt qua thông tin xác thực trên mọi cuộc gọi (không lý tưởng).

Trong trường hợp này, có vẻ như bạn nên sử dụng một trong openAuth (http://www.oAuth.net) - điều này hoạt động bằng cách xác thực khi ứng dụng lần đầu tiên chạy và sau đó tạo mã thông báo truy cập để cho phép truy cập trong mọi cuộc gọi (+ mã thông báo làm mới).

(bạn có thể cho rằng mã thông báo truy cập là trạng thái - loại này là - tuy nhiên, ít nhất nó thường tồn tại lâu hơn đáng kể).

Answer 4

Phương pháp này thường được xem là thực tiễn kém để chuyển dữ liệu nhạy cảm qua yêu cầu HTTP GET.

Thông tin mật khẩu là dữ liệu nhạy cảm và là một trong những ngoại lệ vi phạm quy tắc idempotent operations phải là yêu cầu GET.

Tại sao đây là ngoại lệ? Lịch sử trình duyệt và nhật ký máy chủ sẽ lưu trữ các yêu cầu GET. Có nghĩa là thông tin nhạy cảm này được hiển thị dưới dạng văn bản thuần túy ở cả hai nơi. Vì vậy, nếu ai đó nắm giữ một trong hai - thì thông tin đó hiện nằm trong tay họ.

Bạn nên sử dụng yêu cầu HTTP POST để chuyển thông tin nhạy cảm này đến RESTful API vì trình duyệt sẽ không lưu trữ chúng và máy chủ sẽ không ghi lại chúng. Tuy nhiên, tuyến phòng thủ đầu tiên là sử dụng Secure HTTP (HTTPS) để đảm bảo rằng thông tin này được bảo vệ khỏi người ngoài.

Vì vậy, hãy chuyển thông tin này trong các yêu cầu HTTP của một yêu cầu HTTP tới URL HTTPS.

Answer 5

GET https://api.example.com/auth

Với thiết lập tiêu đề ủy quyền.