Nhảy tới nội dung

id.ocopee.com

Đăng nhập vào Tài khoản Ocopee của bạn và tận dụng tối đa tất cả các dịch vụ Ocopee mà bạn sử dụng. Tài khoản của bạn giúp bạn làm được nhiều việc hơn bằng cách cá nhân hóa trải nghiệm Ocopee của bạn và cung cấp quyền truy cập dễ dàng vào thông tin quan trọng nhất của bạn từ mọi nơi.

Sign in to your Ocopee Account, and get the most out of all the Ocopee services you use. Your account helps you do more by personalizing your Ocopee experience and offering easy access to your most important information from anywhere.

Đạo lý (Philosophy)​

  • Chỉ có một cơ chế xác thực người dùng duy nhất là username, password.
  • Chỉ có một actor duy nhất có thể thực hiện các phương thức của đối tượng. Xác định thông qua Personal Access Token (PAT).
  • Để thực hiện việc phân quyền, cần có mô tả phân quyền để hệ thống sẽ đổi từ PAT của người dùng sang PAT có quyền thực hiện.
  • Xử lý phân quyền có thể linh động nhưng cần gắn id của mô tả phân quyền theo mỗi truy cập để hệ thống truy xuất xử lý nhanh hơn, nghĩa là nếu không được đề cập trong hành động người dùng thì mặc dù có quyền nhưng vẫn không thể sử dụng.

Vậy nên, mục đích cuối cùng của việc xác thực là dựng được dữ liệu của actor trong phiên làm việc. Và việc phân quyền là cơ chế đổi PAT của actor này thành PAT của actor có quyền thực hiện thông qua mô tả phân quyền của người dùng.

👉 Có nên hay không việc lưu trữ và dựng một actor riêng cho ứng dụng dịch vụ?​

Việc dựng một actor riêng phát sinh thêm vấn đề đồng bộ giữa ứng dụng dịch vụ và hệ thống định danh (id.ocopee.com). Nhưng ngược lại giúp cho ứng dụng dễ phát triển và hoạt động tốt hơn. Vậy nên, việc lưu trữ thông tin người dùng chỉ cần lưu trữ các thông tin thực sự cần thiết ví dụ như ID. Còn lại cần gọi trực tiếp để lấy được dữ liệu mới nhất từ hệ thống định danh. Để tăng hiệu suất và giảm số lần gọi, cần có cơ chế lưu tạm có thời hạn để đảm bảo tính mới của dữ liệu.

Ngoài ra, ứng dụng dịch vụ còn thường có trường hợp phân quyền đặc biệt cho chính nghiệp vụ của ứng dụng đó giải quyết. Nên ứng dụng dịch vụ sau khi kế thừa hệ thống phần quyền vẫn có thể phát triển thêm cơ chế phân quyền cho chính nó.

Phân quyền trong đồ án tốt nghiệp năm 2022​

Quyền đại diện​

Khi thực hiện truy vấn dữ liệu, cần xác định nguồn gốc của truy vấn đến từ hostname (domain) nào Quyền đại diện cho truy vấn sử dụng trong trường hợp một user muốn chia sẻ công khai dữ liệu của mình trong hệ thống Multi-tenant.

Điều này cho phép cùng một hệ thống máy chủ giao diện khi cài đặt với các tên miền khác nhau sẽ trả về các kết quả khác nhau.

Quyền hành động​

Quyền sở hữu. Đối với quyền sở hữu. Ai tạo ra dữ liệu thì người đó mới có quyền xóa dữ liệu đó. Cho nên tất cả các bảng đều phải có ghi thông tin người tạo. Bởi vì trong quá trình phát theo yêu cầu thực tế, mối liên hệ giữa các bảng có thể thay đổi nhưng quyền sở hữu giữa dữ liệu đó và người sở hữu không thay đổi.

Nếu tạo ra dữ liệu mà không đăng nhập, không xác định được người sở hữu, thì dữ liệu sẽ thuộc về người đại diện cho truy cập.

Chuyển quyền sở hữu. Khi tạo đơn đặt hàng, tạo nội dung, dữ liệu sản phẩm cho người khác. Phải quyển quyền sở hữu sau đó. Sẽ có nghiệp vụ chạy ngầm để xét duyệt và ghi đè quyền sở hữu cho người thừa kế. Ghi thông tin người tạo vào dữ liệu vào một trường khác nếu cần. Nhưng bản chất dữ liệu đó đã chuyển quyền sở hữu rồi. Nghĩa là, coi như người thừa kế (người được chuyển) tạo ra dữ liệu đó. sau khi chuyển người sở hữu cũ không có quyền xóa nữa.

Quyền xem. đa dạng hơn tùy trường hợp sử dụng.

Quyền xem được thiết đặt theo thứ tự: mặc định, bảng dữ liệu, trường dữ liệu. Nếu định nghĩa quyền xem cho một bảng dữ liệu cụ thể, thì hệ thống sẽ thực hiện định nghĩa đó thay cho quyền mặc định. Tương tự, nếu một trường có định nghĩa quyền xem cho riêng nó, thì khi truy vấn bảng dữ liệu, định nghĩa quyền chỉ áp dụng cho của bảng. Sau đó nếu truy cập hợp lệ vào trường đó thì mới trả về được dữ liệu của trường. (Ví dụ cho trường hợp phân quyền cho trường dữ liệu là khi truy vấn đến bảng người dùng, người xem có thể xem tên, hình ảnh đại diện nhưng không thể xem số điện thoại và mật khẩu đã mã hóa.)

Quyền xem chia ra làm hai loại là phân quyền trực tiếp và phân quyền gián tiếp.

Sơ đồ hoạt động (Workflow)​

Xác thực (Authentication)​

Build-in service​

Yêu cầu người dùng nhập username, password.

  1. Người dùng gửi identity, secret đến hệ thống định danh (OAuth).
  2. So khớp thông tin đăng nhập với cơ sở dữ liệu.
  3. Tạo session.
  4. Mã hóa session ID để trả về cho người dùng (gọi là PAT). PAT này có thời hạn vĩnh viễn và toàn quyền thực hiện với người dùng đó.

Third party service​

Không cần nhập username, password.

  1. Người dùng bấm vào nút đăng nhập.
  2. Ứng dụng dịch vụ yêu cầu OAuth cho phép mình truy cập vào Profile của DAT.
  3. OAuth kèm thông tin ứng dụng gửi về cho người dùng nhắn nhủ lời yêu cầu.
  4. Người dùng đồng ý lời yêu cầu.
  5. OAuth trả về cho máy chủ hoặc người dùng DAT để làm việc.

Using Authed App​

Yêu cầu người dùng đã đăng nhập trước đó bằng App.

  1. Mở một kết nối socket để sẵn sàng cho người dùng đăng nhập, kết nối tồn tại trong 5 phút.
  2. Sử dụng ứng dụng đã đăng nhập (có sẵn PAT hoặc DAT) để quét mã QR.
  3. Ứng dụng nhận được Socket ID và Device Information từ việc quét mã QR.
  4. Ứng dụng gửi lệnh cấp phép cho SocketID nhận PAT hoặc DAT đang mà mình đang sử dụng.
  5. Máy chủ thông qua SocketID gửi PAT hoặc DAT cho người dùng.

Authorization​

Build-in service​

  1. Người dùng gửi PAT đến gateway và request được chuyển tiếp cho build-in service.
  2. Build-in service tìm kiếm dữ liệu trong session thông qua PAT.
  3. Nếu chưa tồn tại session thì thực hiện sign-in bằng cách gọi AuthedItem với PAT hiện tại.o
  4. Tiếp tục xử lý và phản hồi request.

Third party service​

  1. Người dùng gửi một yêu cầu xử lý đến ứng dụng dịch vụ.
  2. Ứng dụng cần gửi DAT của người dùng và PAT của mình để gửi đến OAuth và lấy thông tin người dùng. DAT của người dùng có được sau khi thực hiện workflow đăng đăng nhập. Để cải thiện hiệu suất có thể cache Profile bằng DAT.

    PAT của service hoàn toàn giống với PAT của người dùng. (service cũng được coi là một người dùng)

  3. Phản hồi lại yêu cầu của người dùng.

Với cơ chế này, DAT được sinh ra ở bất kì trang nào cũng có thể sử dụng cho bất cứ các ứng dụng dịch vụ nào miễn ứng dụng đó được người dùng cho phép lấy thông tin từ DAT.

Giao diện (Screen)​

  1. Màn hình đăng nhập gồm usernane, password.
  2. Trạng thái đang đăng xuất và đăng xuất thành công.
  3. Màn hình phần quyền cho biết người dùng đang cấp quyền cho ai, những quyền gì (switch).
  4. Đăng ký (username, password, confirm, OTP, fullname).
  5. Quên mật khẩu (username, email, OTP).
  6. Thông tin cá nhân.

Thêm:

  • Nút "continue with id.ocopee.com"

Session​

Build-in service​

  1. Người dùng gửi truy vấn kèm cookie, PAT, DAT (nếu có)
  2. Nếu có PAT hợp lệ (không quá hạn)
  3. Ký mới hoặc ghi đè giá trị cookie hiện tại.
  4. Dựa trên cookie ở bước 3 để tìm session.
  5. Nếu không có session thì kiểm tra thông tin DAT
  6. Nếu có DAT thì tìm bản ghi DAT đó để thêm vào sesion.
  7. Nếu không có DAT thì chỉ tìm thông tin User dựa trên PAT.

Third party service​

  1. Người dùng gửi truy vấn kèm cookie, DAT (nếu có)
  2. Nếu DAT hợp lệ (không quá hạn)
  3. Ký mới hoặc ghi đè giá trị cookie hiện tại.
  4. Dựa trên cookie ở bước 3 để tìm session.
  5. Tìm thông tin DAT bằng chính PAT của server (server cũng được coi như là một user)

TECHNIQUES​

  • Neo4j
  • NestJS

References​