Các phiên có thực sự vi phạm RESTfulness?


491

Việc sử dụng các phiên trong API RESTful có thực sự vi phạm RESTfulness không? Tôi đã thấy nhiều ý kiến ​​đi theo hướng nào, nhưng tôi không tin rằng các phiên là RESTless . Theo quan điểm của tôi:

  • xác thực không bị cấm đối với RESTfulness (nếu không sẽ có ít sử dụng trong các dịch vụ RESTful)
  • xác thực được thực hiện bằng cách gửi mã thông báo xác thực trong yêu cầu, thường là tiêu đề
  • mã thông báo xác thực này cần phải được lấy bằng cách nào đó và có thể bị thu hồi, trong trường hợp đó cần phải được gia hạn
  • mã thông báo xác thực cần được xác thực bởi máy chủ (nếu không nó sẽ không được xác thực)

Vậy làm thế nào để các phiên vi phạm điều này?

  • phía khách hàng, các phiên được hiện thực hóa bằng cookie
  • cookie chỉ đơn giản là một tiêu đề HTTP bổ sung
  • một cookie phiên có thể được lấy và thu hồi bất cứ lúc nào
  • cookie phiên có thể có thời gian sống vô hạn nếu cần
  • id phiên (mã xác thực) được xác thực phía máy chủ

Như vậy, đối với máy khách, cookie phiên giống hệt như bất kỳ cơ chế xác thực dựa trên tiêu đề HTTP nào khác, ngoại trừ việc nó sử dụng Cookietiêu đề thay vì Authorizationhoặc một số tiêu đề độc quyền khác. Nếu không có phiên nào được gắn vào phía máy chủ giá trị cookie, tại sao điều đó lại tạo ra sự khác biệt? Việc triển khai phía máy chủ không cần phải quan tâm đến máy khách miễn là máy chủ hoạt động RESTful. Do đó, các cookie tự chúng không nên tạo API RESTless và các phiên chỉ đơn giản là cookie cho máy khách.

Là giả định của tôi sai? Điều gì làm cho cookie phiên RESTless ?


5
Tôi đã đề cập đến vấn đề chính xác ở đây: stackoverflow.com/questions/1296421/rest-complex-appluggest/ mẹo
Will Hartung

5
Để thêm vào đó, nếu bạn chỉ sử dụng phiên để xác thực, thì tại sao không sử dụng các tiêu đề được cung cấp? Nếu không, và bạn đang sử dụng phiên cho trạng thái khác của cuộc trò chuyện, thì điều đó vi phạm ràng buộc không trạng thái của REST.
Will Hartung

2
@ Sẽ cảm ơn. Có vẻ như bạn đang nói về các phiên để lưu trữ tạm thời dữ liệu do người dùng gửi, trong trường hợp của tôi, tôi chỉ nói về chúng như một chi tiết triển khai để xác thực. Có thể đây là nơi bất đồng đến từ đâu?
lừa dối

3
@deceze Điểm duy nhất của tôi là nếu bạn sẽ sử dụng một tiêu đề để thể hiện mã thông báo xác thực, HTTP cung cấp một tiêu đề vượt ra ngoài một cookie chung. Vì vậy, tại sao không sử dụng điều đó và giữ ngữ nghĩa miễn phí mà bạn có với nó (bất kỳ ai nhìn thấy tải trọng đều có thể thấy có mã thông báo xác thực được gán cho nó).
Will Hartung

7
Chắc chắn, nhưng sau đó tại sao không tạo tiêu đề của riêng bạn hoặc chiếm quyền điều khiển một số tiêu đề khác cho mã thông báo xác thực. Sử dụng tiêu đề X-XYZZY. Đó chỉ là cú pháp phải không? Các tiêu đề truyền đạt thông tin. Tiêu đề ủy quyền là "tài liệu tự" hơn so với cookie của bạn, bởi vì "mọi người" đều biết tiêu đề Auth dùng để làm gì. Nếu họ chỉ nhìn thấy JSESSIONID (hoặc bất cứ điều gì), họ không thể đưa ra bất kỳ giả định nào, hoặc tệ hơn, đưa ra các giả định sai (anh ta còn lưu trữ gì trong phiên, cái này được sử dụng để làm gì, v.v.). Bạn có đặt tên cho biến của mình trong mã Aq12hsg không? Tất nhiên là không rồi. Điều tương tự áp dụng ở đây.
Will Hartung

Câu trả lời:


299

Đầu tiên, hãy xác định một số thuật ngữ:

  • PHỤC HỒI:

    Người ta có thể mô tả các ứng dụng tuân theo các ràng buộc REST được mô tả trong phần này là "RESTful". [15] Nếu một dịch vụ vi phạm bất kỳ ràng buộc cần thiết nào, thì nó không thể được coi là RESTful.

    theo wikipedia .

  • ràng buộc không quốc tịch:

    Tiếp theo, chúng tôi thêm một ràng buộc cho tương tác giữa máy khách và máy chủ: giao tiếp phải có bản chất không trạng thái, như trong kiểu máy khách không trạng thái (CSS) của Phần 3.4.3 (Hình 5-3), sao cho mỗi yêu cầu từ máy khách đến máy chủ phải chứa tất cả thông tin cần thiết để hiểu yêu cầu và không thể tận dụng bất kỳ bối cảnh được lưu trữ nào trên máy chủ. Do đó trạng thái phiên được giữ hoàn toàn trên máy khách.

    theo luận án Fielding .

Vì vậy, các phiên phía máy chủ vi phạm ràng buộc không trạng thái của REST và RESTfulness cũng vậy.

Như vậy, đối với máy khách, cookie phiên giống hệt như mọi cơ chế xác thực dựa trên tiêu đề HTTP khác, ngoại trừ việc nó sử dụng tiêu đề Cookie thay vì Ủy quyền hoặc một số tiêu đề độc quyền khác.

Theo cookie phiên, bạn lưu trữ trạng thái máy khách trên máy chủ và do đó yêu cầu của bạn có ngữ cảnh. Hãy thử thêm một bộ cân bằng tải và một thể hiện dịch vụ khác vào hệ thống của bạn. Trong trường hợp này, bạn phải chia sẻ các phiên giữa các phiên bản dịch vụ. Thật khó để duy trì và mở rộng một hệ thống như vậy, vì vậy nó có quy mô xấu ...

Theo tôi không có gì sai với cookie. Công nghệ cookie là một cơ chế lưu trữ phía máy khách trong đó dữ liệu được lưu trữ được gắn tự động vào các tiêu đề cookie theo mọi yêu cầu. Tôi không biết về một ràng buộc REST có vấn đề với loại công nghệ đó. Vì vậy, không có vấn đề với chính công nghệ, vấn đề là với cách sử dụng của nó. Fielding đã viết một phần phụ về lý do tại sao anh ta nghĩ cookie HTTP là xấu.

Theo quan điểm của tôi:

  • xác thực không bị cấm đối với RESTfulness (nếu không sẽ có ít sử dụng trong các dịch vụ RESTful)
  • xác thực được thực hiện bằng cách gửi mã thông báo xác thực trong yêu cầu, thường là tiêu đề
  • mã thông báo xác thực này cần phải được lấy bằng cách nào đó và có thể bị thu hồi, trong trường hợp đó cần phải được gia hạn
  • mã thông báo xác thực cần được xác thực bởi máy chủ (nếu không nó sẽ không được xác thực)

Quan điểm của bạn là khá vững chắc. Vấn đề duy nhất là với khái niệm tạo mã thông báo xác thực trên máy chủ. Bạn không cần phần đó. Những gì bạn cần là lưu trữ tên người dùng và mật khẩu trên máy khách và gửi nó với mọi yêu cầu. Bạn không cần nhiều thứ để làm điều này hơn xác thực cơ bản HTTP và kết nối được mã hóa:

Hình 1. - Xác thực không trạng thái bởi các khách hàng đáng tin cậy

  • Hình 1. - Xác thực không trạng thái bởi các khách hàng đáng tin cậy

Bạn có thể cần một bộ đệm auth trong bộ nhớ ở phía máy chủ để làm cho mọi thứ nhanh hơn, vì bạn phải xác thực mọi yêu cầu.

Bây giờ điều này hoạt động khá tốt bởi các khách hàng đáng tin cậy được viết bởi bạn, nhưng còn khách hàng bên thứ 3 thì sao? Họ không thể có tên người dùng và mật khẩu và tất cả các quyền của người dùng. Vì vậy, bạn phải lưu trữ riêng những quyền mà khách hàng bên thứ 3 có thể có đối với người dùng cụ thể. Vì vậy, các nhà phát triển ứng dụng khách có thể đăng ký họ là khách hàng của bên thứ 3 và nhận một khóa API duy nhất và người dùng có thể cho phép khách hàng của bên thứ 3 truy cập một số quyền của họ. Giống như đọc tên và địa chỉ email, hoặc liệt kê bạn bè của họ, v.v ... Sau khi cho phép khách hàng bên thứ 3, máy chủ sẽ tạo mã thông báo truy cập. Các mã thông báo truy cập này có thể được sử dụng bởi ứng dụng khách bên thứ 3 để truy cập các quyền do người dùng cấp, như vậy:

Hình 2. - Xác thực không trạng thái của khách hàng bên thứ 3

  • Hình 2. - Xác thực không trạng thái của khách hàng bên thứ 3

Vì vậy, ứng dụng khách bên thứ 3 có thể nhận được mã thông báo truy cập từ một khách hàng đáng tin cậy (hoặc trực tiếp từ người dùng). Sau đó, nó có thể gửi yêu cầu hợp lệ bằng khóa API và mã thông báo truy cập. Đây là cơ chế xác thực của bên thứ 3 cơ bản nhất. Bạn có thể đọc thêm về các chi tiết triển khai trong tài liệu của mọi hệ thống xác thực của bên thứ 3, ví dụ OAuth. Tất nhiên điều này có thể phức tạp và an toàn hơn, ví dụ bạn có thể ký chi tiết của từng yêu cầu ở phía máy chủ và gửi chữ ký cùng với yêu cầu, v.v ... Giải pháp thực tế phụ thuộc vào nhu cầu của ứng dụng của bạn.


5
Vâng, bạn hoàn toàn đúng. Vì tôi đã đăng câu hỏi này nên tôi hoàn toàn quay lại để thấy điều đó. Cookie phiên không có gì đặc biệt khi xem xét các chi tiết kỹ thuật, nhưng điều đó thiếu rừng cho cây. Chấp nhận câu trả lời của bạn vì các biểu đồ tốt đẹp. ;)
lừa dối

1
Ok, tôi đã suy nghĩ lại, phản hồi của dịch vụ REST không nên phụ thuộc vào ủy quyền, vì vậy tôi nghĩ rằng 2 giải pháp đầu tiên đều ổn 100% và các giải pháp khác đều ổn nếu dịch vụ chỉ sử dụng thông tin để quyết định xem nó có cho phép yêu cầu hay không không phải. Vì vậy, tôi nghĩ rằng các quyền của người dùng sẽ ảnh hưởng đến việc thể hiện tài nguyên hiện tại.
inf3rno

1
Tôi sẽ tạo một câu hỏi về sự phụ thuộc quyền của các đại diện. Tôi sẽ mở rộng câu trả lời này ngay khi tôi có giải pháp thích hợp.
inf3rno

3
@ inf3rno, đúng là một dịch vụ RESTful hoàn toàn không thể phụ thuộc vào cookie phiên để xác thực theo cách truyền thống được triển khai. Tuy nhiên, bạn có thể sử dụng cookie để thực hiện xác thực nếu cookie chứa tất cả thông tin trạng thái mà máy chủ sẽ cần sau này. Bạn cũng có thể làm cho cookie an toàn khỏi giả mạo bằng cách ký nó với cặp khóa công khai / riêng tư. Xem những bình luận của tôi bên dưới.
jcoffland

3
Tôi không hiểu tại sao mọi người dường như chấp nhận nhận xét mà bạn nên lưu trữ mật khẩu ở phía khách hàng và gửi chúng với mọi yêu cầu. Đây là một thực tế rất xấu và gây nguy hiểm cho dữ liệu nhạy cảm của khách hàng của bạn. Một mật khẩu chưa được xóa (mà nó sẽ phải được gửi đi gửi lại) không bao giờ được lưu trữ ở bất cứ đâu. Nếu chúng tôi chấp nhận điều này thì bạn đang sử dụng mã thông báo như hầu hết các hệ thống xác thực làm, trong trường hợp đó, bất kỳ cơ chế nào chúng tôi sử dụng để mở rộng kho lưu trữ mã thông báo sẽ có hầu hết các mối lo ngại về khả năng mở rộng như bất kỳ khả năng mở rộng phiên nào.
lvoelk

334

Trước hết, REST không phải là một tôn giáo và không nên tiếp cận như vậy. Mặc dù có những lợi thế đối với các dịch vụ RESTful, bạn chỉ nên tuân theo các nguyên lý của REST khi chúng có ý nghĩa đối với ứng dụng của bạn.

Điều đó nói rằng, xác thực và trạng thái phía máy khách không vi phạm các nguyên tắc REST. Mặc dù REST yêu cầu chuyển trạng thái là không trạng thái, nhưng điều này đề cập đến chính máy chủ. Tại trung tâm, tất cả các REST là về tài liệu. Ý tưởng đằng sau trạng thái không trạng thái là SERVER không trạng thái, không phải máy khách. Bất kỳ khách hàng nào đưa ra một yêu cầu giống hệt nhau (cùng tiêu đề, cookie, URI, v.v.) nên được đưa đến cùng một vị trí trong ứng dụng. Nếu trang web lưu trữ vị trí hiện tại của người dùng và điều hướng được quản lý bằng cách cập nhật biến điều hướng phía máy chủ này, thì REST sẽ bị vi phạm. Một khách hàng khác có thông tin yêu cầu giống hệt nhau sẽ được đưa đến một vị trí khác tùy thuộc vào trạng thái phía máy chủ.

Các dịch vụ web của Google là một ví dụ tuyệt vời về hệ thống RESTful. Họ yêu cầu một tiêu đề xác thực với khóa xác thực của người dùng được chuyển qua mỗi yêu cầu. Điều này không vi phạm các nguyên tắc REST một chút, bởi vì máy chủ đang theo dõi trạng thái của khóa xác thực. Trạng thái của khóa này phải được duy trì và nó có một số loại ngày / thời gian hết hạn mà sau đó nó không còn cấp quyền truy cập. Tuy nhiên, như tôi đã đề cập ở đầu bài viết của mình, phải hy sinh để cho phép một ứng dụng thực sự hoạt động. Điều đó nói rằng, mã thông báo xác thực phải được lưu trữ theo cách cho phép tất cả các khách hàng có thể tiếp tục cấp quyền truy cập trong thời gian hợp lệ của họ. Nếu một máy chủ đang quản lý trạng thái của khóa xác thực đến điểm mà máy chủ cân bằng tải khác có thể đảm nhận việc thực hiện các yêu cầu dựa trên khóa đó, bạn đã bắt đầu thực sự vi phạm các nguyên tắc của REST. Các dịch vụ của Google đảm bảo rằng, bất cứ lúc nào, bạn có thể lấy mã thông báo xác thực bạn đang sử dụng trên điện thoại của mình chống lại máy chủ cân bằng tải A và nhấn máy chủ cân bằng tải B từ máy tính để bàn của bạn và vẫn có quyền truy cập vào hệ thống và được chuyển đến cùng một tài nguyên nếu các yêu cầu là giống hệt nhau.

Tất cả những gì có thể hiểu là bạn cần đảm bảo mã thông báo xác thực của bạn được xác thực dựa trên kho lưu trữ sao lưu (cơ sở dữ liệu, bộ đệm, bất cứ thứ gì) để đảm bảo rằng bạn giữ được càng nhiều thuộc tính REST càng tốt.

Tôi hy vọng tất cả điều đó có ý nghĩa. Bạn cũng nên xem phần Ràng buộc của bài viết trên wikipedia về Chuyển giao trạng thái đại diện nếu bạn chưa có. Nó đặc biệt khai sáng liên quan đến những gì các nguyên lý của REST đang thực sự tranh luận và tại sao.


6
Tôi sẽ viết lại tuyên bố ban đầu của bạn. Chỉ sử dụng REST nếu các ràng buộc của REST có ý nghĩa đối với ứng dụng của bạn. Bạn có thể tự do áp dụng một tập hợp con của những ràng buộc đó và bạn sẽ nhận được một tập hợp con các lợi ích. Tuy nhiên, tại thời điểm đó bạn đã tạo ra phong cách kiến ​​trúc của riêng bạn. Tuy nhiên, đó không phải là điều xấu, thực tế đó là những gì trong bốn chương đầu tiên của luận án Roy, về thiết kế nguyên tắc. REST chỉ là một ví dụ.
Darrel Miller

4
@Darrel Một điểm đủ công bằng. Tôi thực sự không chắc chắn làm thế nào Google làm điều đó, nhưng thời gian hết hạn có thể được mã hóa vào mã thông báo xác thực. Tôi tin rằng điểm lớn hơn của tôi vẫn đứng mặc dù. Có một số loại trạng thái đơn giản phải được duy trì và miễn là bạn hiểu tại sao REST yêu cầu trạng thái không trạng thái, bạn có thể vi phạm nó theo cách có ý nghĩa với nhiều hậu quả trên phần còn lại của hệ thống và những lợi thế của kiến ​​trúc RESTful .
Jared Harding

7
Vì không có lập luận nào khác được đưa ra cho đến nay, tôi chấp nhận phản hồi bằng văn bản này. Tôi nghĩ phần quan trọng là máy chủ không trạng thái không có nghĩa là máy chủ không trạng thái , một cái gì đó mà tôi nghĩ thường bị hiểu lầm hoặc áp dụng sai. Các máy chủ có thể (và thường phải ) có bất cứ tiểu bang nó muốn, miễn là nó cư xử idempotent .
lừa dối

10
Tôi đã nghe rất nhiều lời rao giảng rằng các phiên không được nghỉ ngơi. Xác thực cơ bản HTTP là một bước lùi thực sự nếu bạn đang cố gắng xây dựng một ứng dụng web.
Ben Thurley

1
@Micah Henning, bạn đang đưa ra giả định sai lầm rằng máy chủ yêu cầu thông tin trạng thái để xác thực mã thông báo xác thực. Chúng tôi có thể giả định một cách hợp lý rằng bạn không thể giả mạo mã thông báo đã được ký bởi cặp khóa công khai / riêng nếu bạn không biết khóa riêng. Để xác minh mã thông báo là hợp lệ, tất cả những gì bạn cần là khóa chung. Tôi vẫn giữ xác thực RESTful hoàn toàn là có thể.
jcoffland

12

Cookies không phải để xác thực. Tại sao phải phát minh lại một bánh xe? HTTP có các cơ chế xác thực được thiết kế tốt. Nếu chúng tôi sử dụng cookie, chúng tôi chỉ sử dụng HTTP làm giao thức truyền tải, do đó chúng tôi cần tạo hệ thống báo hiệu của riêng mình , ví dụ, để nói với người dùng rằng họ cung cấp xác thực sai (sử dụng HTTP 401 sẽ không chính xác vì có lẽ chúng tôi sẽ không cung cấp Www-Authenticatecho khách hàng, như thông số kỹ thuật HTTP yêu cầu :)). Cũng cần lưu ý rằng đó Set-Cookiechỉ là một khuyến nghị cho khách hàng. Nội dung của nó có thể hoặc không thể được lưu (ví dụ: nếu cookie bị tắt), trong khi Authorizationtiêu đề được gửi tự động theo mọi yêu cầu.

Một điểm khác là, để có được một cookie ủy quyền, trước tiên bạn có thể muốn cung cấp thông tin đăng nhập của mình ở đâu không? Nếu vậy, nó sẽ không phải là RESTless? Ví dụ đơn giản:

  • Bạn thử GET /amà không có cookie
  • Bạn nhận được một yêu cầu ủy quyền bằng cách nào đó
  • Bạn đi và ủy quyền bằng cách nào đó như POST /auth
  • Bạn lấy Set-Cookie
  • Bạn thử GET /a với cookie. Nhưng liệu có GET /acư xử bình thường trong trường hợp này?

Tóm lại, tôi tin rằng nếu chúng ta truy cập một số tài nguyên và chúng ta cần xác thực, thì chúng ta phải xác thực trên cùng một tài nguyên đó chứ không phải bất kỳ nơi nào khác.


1
Trong khi đó, tôi cũng tìm hiểu thêm về quan điểm này. Tôi nghĩ rằng về mặt kỹ thuật, nó tạo ra rất ít sự khác biệt, tất cả chỉ là tiêu đề HTTP. Mặc dù đúng là hành vi xác thực không phải là RESTful, nếu đăng nhập thông qua một địa chỉ riêng biệt là bắt buộc. Vì vậy, cookie chỉ là một triệu chứng của một vấn đề lớn hơn với hệ thống xác thực.
lừa dối

Điều này không thực sự giải thích cho thực tế là các trình duyệt web chỉ hỗ trợ Authorization: Basichoặc Digest. Nếu bạn muốn làm bất cứ điều gì cao cấp hơn cơ bản hoặc tiêu hóa auth (và bạn nên) trong ngữ cảnh trình duyệt, thì bạn sẽ cần một cái gì đó ngoài Authorizationtiêu đề.
Oliver Charlesworth

1
Hoàn toàn - nếu bạn đang thực hiện JS thuần túy thì mọi thứ về cơ bản đều ổn (ngoại trừ, ví dụ, Websockets). Nhưng quan điểm của tôi là auth dựa trên API không nhất thiết phải là sự cân nhắc duy nhất trong kịch bản trình duyệt.
Oliver Charlesworth

5
GET /akhông có cookie và với cookie rõ ràng là hai yêu cầu khác nhau và chúng có thể chấp nhận hành vi khác nhau.
TRiG

1
Để thêm vào @TRiG, ​​theo logic này, GET /avới tiêu đề xác thực cũng giống như GET /akhông có tiêu đề xác thực, làm cho nó không thể sử dụng được cho REST. Nếu bạn sẽ đối xử với một tiêu đề http khác với tiêu đề khác, thì ít nhất bạn sẽ giải quyết vấn đề đó.
Jasper

7

Trên thực tế, RESTfulness chỉ áp dụng cho TÀI NGUYÊN, như được chỉ định bởi Mã định danh tài nguyên chung. Vì vậy, để thậm chí nói về những thứ như tiêu đề, cookie, vv liên quan đến REST là không thực sự phù hợp. REST có thể hoạt động trên bất kỳ giao thức nào, mặc dù nó được thực hiện thường xuyên qua HTTP.

Công cụ xác định chính là đây: nếu bạn gửi một cuộc gọi REST, là một URI, thì một khi cuộc gọi thực hiện thành công đến máy chủ, URI đó có trả lại cùng một nội dung không, giả sử không có chuyển đổi nào được thực hiện (PUT, POST, DELETE) ? Thử nghiệm này sẽ loại trừ các lỗi hoặc yêu cầu xác thực được trả về, vì trong trường hợp đó, yêu cầu chưa được gửi đến máy chủ, nghĩa là servlet hoặc ứng dụng sẽ trả về tài liệu tương ứng với URI đã cho.

Tương tự, trong trường hợp POST hoặc PUT, bạn có thể gửi URI / payload nhất định không, và bất kể bạn gửi tin nhắn bao nhiêu lần, nó sẽ luôn cập nhật cùng một dữ liệu, để các GET tiếp theo sẽ trả về kết quả nhất quán?

REST là về dữ liệu ứng dụng, không phải về thông tin cấp thấp cần thiết để truyền dữ liệu đó.

Trong bài đăng trên blog sau đây, Roy Fielding đã đưa ra một bản tóm tắt hay về toàn bộ ý tưởng REST:

http://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/5841

"Một hệ thống RESTful tiến triển từ trạng thái ổn định sang trạng thái tiếp theo và mỗi trạng thái ổn định như vậy vừa là trạng thái bắt đầu tiềm năng vừa là trạng thái kết thúc tiềm năng. Tức là, hệ thống RESTful là một số thành phần không xác định tuân theo một bộ đơn giản các quy tắc sao cho chúng luôn ở trạng thái REST hoặc chuyển từ trạng thái RESTful sang trạng thái RESTful khác. Mỗi trạng thái có thể được hiểu hoàn toàn bởi (các) đại diện mà nó chứa và tập hợp các chuyển đổi mà nó cung cấp, với các chuyển đổi giới hạn trong một thống nhất Hệ thống có thể là một sơ đồ trạng thái phức tạp, nhưng mỗi tác nhân người dùng chỉ có thể nhìn thấy một trạng thái tại một thời điểm (trạng thái ổn định hiện tại) và do đó mỗi trạng thái là đơn giản và có thể được phân tích độc lập. người dùng, OTOH, có thể tạo chuyển tiếp của riêng họ bất cứ lúc nào (ví dụ: nhập URL, chọn dấu trang,mở một trình soạn thảo, v.v.). "


Đi đến vấn đề xác thực, cho dù nó được thực hiện thông qua cookie hay tiêu đề, miễn là thông tin không phải là một phần của tải trọng URI và POST, nó thực sự không liên quan gì đến REST. Vì vậy, liên quan đến việc không quốc tịch, chúng tôi chỉ nói về dữ liệu ứng dụng.

Ví dụ: khi người dùng nhập dữ liệu vào màn hình GUI, máy khách sẽ theo dõi những trường nào đã được nhập, trường nào không, bất kỳ trường bắt buộc nào bị thiếu, v.v ... Đây là tất cả TIẾP TỤC KHÁCH HÀNG, và không nên gửi hoặc theo dõi bởi máy chủ. Những gì được gửi đến máy chủ là tập hợp đầy đủ các trường cần được sửa đổi trong tài nguyên IDENTifyED (bởi URI), sao cho quá trình chuyển đổi xảy ra trong tài nguyên đó từ trạng thái RESTful này sang trạng thái RESTful khác.

Vì vậy, khách hàng theo dõi những gì người dùng đang làm và chỉ gửi các chuyển trạng thái hoàn thành logic đến máy chủ.


3
Tôi không thấy làm thế nào điều này làm sáng tỏ bất kỳ câu hỏi đặt ra.
jcoffland

1

Giao dịch HTTP, xác thực truy cập cơ bản, không phù hợp với RBAC, vì xác thực truy cập cơ bản sử dụng tên người dùng được mã hóa: mật khẩu mỗi lần để xác định, trong khi điều cần thiết trong RBAC là Vai trò mà người dùng muốn sử dụng cho một cuộc gọi cụ thể. RBAC không xác thực quyền trên tên người dùng, nhưng về vai trò.

Bạn có thể thử xung quanh để nối như thế này: usernameRole: mật khẩu, nhưng đây là cách làm không tốt và nó cũng không hiệu quả vì khi người dùng có nhiều vai trò hơn, công cụ xác thực sẽ cần kiểm tra tất cả các vai trò trong kết nối và mỗi lần gọi lại. Điều này sẽ phá hủy một trong những lợi thế kỹ thuật lớn nhất của RBAC, cụ thể là thử nghiệm ủy quyền rất nhanh.

Vì vậy, vấn đề đó không thể được giải quyết bằng cách sử dụng xác thực truy cập cơ bản.

Để giải quyết vấn đề này, việc duy trì phiên là cần thiết và dường như, theo một số câu trả lời, mâu thuẫn với REST.

Đó là những gì tôi thích về câu trả lời rằng REST không nên được coi là một tôn giáo. Trong các trường hợp kinh doanh phức tạp, ví dụ như trong chăm sóc sức khỏe, RBAC là hoàn toàn phổ biến và cần thiết. Và thật đáng tiếc nếu họ không được phép sử dụng REST vì tất cả các nhà thiết kế công cụ REST sẽ coi REST như một tôn giáo.

Đối với tôi không có nhiều cách để duy trì phiên qua HTTP. Người ta có thể sử dụng cookie, với sessionId hoặc tiêu đề với sessionId.

Nếu ai đó có ý tưởng khác tôi sẽ rất vui khi nghe nó.



-4
  1. Phiên không phải là RESTless
  2. Bạn có nghĩa là dịch vụ REST chỉ sử dụng http hoặc tôi đã sai? Phiên dựa trên cookie phải được sử dụng chỉ cho các dịch vụ dựa trên http (!) Của riêng! (Đây có thể là một vấn đề khi làm việc với cookie, ví dụ như từ Mobile / Console / Desktop / v.v.)
  3. nếu bạn cung cấp dịch vụ RESTful cho nhà phát triển bên 3d, không bao giờ sử dụng phiên dựa trên cookie, thay vào đó hãy sử dụng mã thông báo để tránh các vấn đề về bảo mật.

3
không nên sử dụng cookie để lưu trữ khóa phiên cho phiên trên máy chủ chứa mã xác thực. nhưng nếu cookie giữ mã thông báo xác thực thì đó là một giải pháp khả thi. (tất nhiên cookie phải được httponly và bảo mật)
roberkules
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.