7

CONTEXT:Mã thông báo xác thực của Ember.js cho dữ liệu Ember-AMS => JSON hoặc HTTP Header?

Tôi có ứng dụng Ember.js 1.1.0-beta.1 trao đổi dữ liệu JSON với máy chủ Rails-API (Rails 4). Trao đổi dữ liệu JSON được thực hiện với Ember-Data 1.0.0-beta.2 và Serial Model hoạt động 0.8.1 (AMS). Tôi đang sử dụng cấu hình được đề xuất mặc định cho cả dữ liệu Ember-Data và AMS, đồng thời tuân thủ thông số JSON-API.

Trên bất kỳ cuộc gọi RESTful đã cho nào, máy khách sẽ chuyển mã thông báo xác thực hiện tại đến máy chủ. Mã xác thực được xác minh và gỡ bỏ và mã thông báo xác thực mới được tạo và gửi lại cho khách hàng. Do đó, mọi cuộc gọi RESTful đều chấp nhận một mã thông báo xác thực trong yêu cầu và cung cấp một mã thông báo xác thực mới trong câu trả lời rằng máy khách có thể cache và sử dụng cho cuộc gọi RESTful tiếp theo.

CÂU HỎI:

Tôi đặt mã thông báo xác thực vào mỗi yêu cầu và phản hồi ở đâu?

Nếu nó là một phần của JSON của đối tượng trong yêu cầu và phản hồi? Nếu vậy, mã thông báo được đặt trong cấu trúc JSON của đối tượng hiện tại (không có gì liên quan đến xác thực)?

Hoặc chúng có được đặt trong tiêu đề HTTP cho từng đối tượng yêu cầu và phản hồi không?

"Ember Way" mà người ta cuối cùng có thể mong đợi để tìm thấy trong sách hướng dẫn Ember Hướng dẫn mới là gì? BỐI CẢNH

THÊM:

Tôi đã quen thuộc với các liên kết sau đây:

... và đang tìm câu trả lời vượt ra ngoài những điều này và cụ thể cho Ember-Data + AMS.

Ngoại trừ sự cần thiết phải vượt qua một thẻ mới lại cho khách hàng trong việc ứng phó qua Ember-Data, giả mã khách hàng của tôi là khác tương tự như Embercast dụ @machty trên GitHub: https://github.com/embercasts/authentication-part-2/blob/master/public/js/app.js

Cảm ơn bạn rất nhiều!

Trả lời

2

Tôi đã xây dựng một cái gì đó tương tự, mặc dù tôi không đặt lại mã thông báo trừ khi người dùng đăng xuất.

Tôi sẽ không đặt nó trong chính cơ thể yêu cầu - bạn sẽ chỉ gây ô nhiễm cho các mô hình của mình. Có lẽ không có cách nào Ember vì đây là vấn đề vận chuyển nhiều hơn. Tôi chuyển mã thông báo bằng tiêu đề HTTP tùy chỉnh và/hoặc cookie. Cookie là cần thiết để cho phép tải xuống tệp, không thể thực hiện thông qua ajax, mặc dù cookie cũng hoạt động cho các cuộc gọi ajax. Trong trường hợp của bạn, tôi sẽ sử dụng một cookie và có máy chủ đặt nó vào giá trị mới mỗi lần. Tuy nhiên, lược đồ đặt lại mã thông báo của bạn trên mỗi yêu cầu JSON sẽ không hoạt động trên các yêu cầu đồng thời. Điều này có thực sự cần thiết không? Nếu bạn sử dụng TLS bạn có thể không cần phải lo lắng quá nhiều. Bạn cũng có thể hết thời gian để mã thông báo nếu không có yêu cầu nào trong 10 phút thì mã thông báo mới sẽ được tạo.

3

Tôi có một ngăn xếp tương tự - ember, dữ liệu ember và rails-api với AMS. Ngay bây giờ, tôi chỉ chuyển mã thông báo xác thực (mà tôi lưu trữ trong localStorage) trong một tiêu đề (mặc dù bạn có thể truyền nó trên chuỗi truy vấn) bằng cách sửa đổi phương thức của RESTAdapter.

Suy nghĩ ban đầu của tôi là tránh đặt lại mã thông báo trên mọi yêu cầu. Nếu bạn đặc biệt quan tâm đến mã thông báo bị ngửi, có thể dễ dàng hơn khi chỉ đặt lại mã thông báo trên máy chủ ở khoảng thời gian thông thường (ví dụ: 10 phút). Sau đó, nếu bất kỳ yêu cầu nào từ máy khách không thành công do mã thông báo cũ, chỉ cần tìm nạp mã thông báo mới (bằng cách chuyển mã thông báo 'mà máy chủ của bạn cung cấp cho bạn khi đăng nhập) và phát lại yêu cầu ban đầu.

Đối với vị trí đặt mã thông báo, không thực sự là "Đường Ember" - Tôi thích chuyển nó trong tiêu đề vì chuyển nó trong chuỗi truy vấn có thể gây rối với bộ nhớ đệm và cũng có nhiều khả năng được ghi ở đâu đó dọc đường. Tôi chắc chắn sẽ tránh đi qua nó trong cơ thể yêu cầu - điều đó sẽ đi ngược lại những gì dữ liệu ember mong đợi, tôi sẽ tưởng tượng.