Lập trình với API
Lập trình với APIPhơi bày các endpoint công khai và riêng tư

Phơi bày các endpoint công khai và riêng tư

GraphQL truyền thống tập trung vào việc phơi bày một endpoint duy nhất, thường nằm tại https://mysite.com/graphql.

Gato GraphQL mở rộng khái niệm này, cho phép chúng ta phơi bày nhiều endpoint tùy chỉnh, mỗi endpoint phù hợp với một nhu cầu cụ thể. Ví dụ, chúng ta có thể phơi bày các endpoint:

  • /internal/public
  • /apps/mobile/apps/website
  • /clients/visitors
  • /development, /staging/production
  • /teams/development, /teams/testing/teams/marketing
  • /clients/A, /clients/Bclients/Z
  • bất kỳ sự kết hợp nào trong số đó

Gato GraphQL cũng hỗ trợ Persisted Queries, là các endpoint trong đó GraphQL query đã được xác định trước và lưu trữ trên máy chủ.

Hướng dẫn này trình bày các gợi ý về cách và thời điểm sử dụng từng endpoint.

Ngoài việc bảo mật các endpoint API Gato GraphQL của bạn, chúng tôi khuyến nghị bạn luôn tăng cường bảo mật trang web WordPress bằng một plugin bảo mật chuyên dụng, chẳng hạn như WP Security Ninja.

Các endpoint được cấu hình thông qua một Cấu hình Schema, trong đó chúng ta xác định:

  • Đặt schema ở chế độ công khai hoặc riêng tư
  • Bật các phần tử dữ liệu "nhạy cảm"
  • Đặt namespace cho schema
  • Sử dụng nested mutations
  • Xác định các response header
  • Cấp quyền truy cập vào các phần tử schema thông qua Access Control Lists
  • Thiết lập bộ nhớ đệm HTTP
  • Và nhiều tùy chọn khác

Nếu chúng ta có một cấu hình muốn áp dụng cho tất cả hoặc hầu hết các endpoint, chúng ta có thể xác định một Cấu hình Schema mặc định.

Khi nào nên dùng endpoint đơn

Endpoint đơn luôn công khai, được phơi bày mặc định tại /graphql.

Gato GraphQL được quản lý thông qua các "module", mỗi module cung cấp một chức năng hoặc mở rộng schema GraphQL, và có thể được bật hoặc tắt theo nhu cầu.

Để tăng cường bảo mật API, một thực hành tốt là tắt các module mở rộng schema GraphQL (chẳng hạn như các module "Posts", "Users", "Comments", "Blocks", v.v.) khi chúng không cần thiết, để đảm bảo rằng dữ liệu đó sẽ không bao giờ bị phơi bày ngay từ đầu.

Đặc biệt, nếu API không có mục đích thay đổi dữ liệu (tức là tạo hoặc cập nhật tài nguyên), một thực hành tốt là tắt module "Mutations". Làm vậy sẽ đồng thời tắt tất cả các extension cung cấp mutation (chẳng hạn như các module "Post Mutations", "Comment Mutations", v.v.), và các mutation này sẽ không bao giờ bị phơi bày trong schema GraphQL.

Endpoint đơn được khuyến nghị khi:

  • Chúng ta cần lấy dữ liệu để hỗ trợ một tính năng duy nhất, và
  • Trang web WordPress không thể truy cập từ Internet công cộng (tức là nó đang chạy trên máy tính phát triển, hoặc đằng sau tường lửa)

Đây là trường hợp, ví dụ, khi xây dựng một trang headless (sử dụng Next.js, Gatsby, hoặc các framework khác).

Khi nào nên dùng endpoint tùy chỉnh công khai

Các endpoint tùy chỉnh tương tự như endpoint đơn, nhưng chúng ta có thể có nhiều endpoint, mỗi endpoint được phơi bày tại URL riêng của nó graphql/{custom-endpoint-slug}/, và mỗi endpoint có cấu hình khác nhau.

Các endpoint tùy chỉnh cung cấp bảo mật thông qua sự mơ hồ, vì chỉ đối tượng mục tiêu mới biết về sự tồn tại của endpoint tùy chỉnh và URL của nó.

Để tăng cường bảo mật API, chúng ta có thể sử dụng extension Access Control để cấp quyền truy cập vào endpoint chỉ khi:

  • Người dùng đã đăng nhập (hoặc chưa)
  • Người dùng có một vai trò nhất định
  • Người dùng có một khả năng nhất định
  • Khách truy cập đến từ một IP được phép (thông qua extension Access Control: Visitor IP)

Mỗi endpoint tùy chỉnh có thể có Access Control List riêng, do đó chỉ người dùng mục tiêu cụ thể của nó mới có thể truy cập.

Các endpoint tùy chỉnh được khuyến nghị khi chúng ta cần quản lý và tùy chỉnh quyền truy cập vào API, dù là từ các ứng dụng, nhóm, khách hàng hay đối tượng khác nhau.

Khi nào nên dùng endpoint tùy chỉnh riêng tư

Gato GraphQL triển khai các endpoint tùy chỉnh thông qua Custom Post Types (CPTs). Điều này cho phép chúng ta xuất bản endpoint tùy chỉnh ở chế độ private (và cả password-protected), khiến endpoint tùy chỉnh chỉ có thể truy cập được bởi người dùng đã đăng nhập có quyền truy cập vào custom post đó, và không ai khác.

Phương thức này được khuyến nghị khi endpoint GraphQL chỉ dành cho quản trị viên của trang web (chẳng hạn như khi dùng GraphQL để thực hiện các tác vụ quản trị). Bằng cách chặn hoàn toàn khách truy cập bên ngoài không thể truy cập endpoint, chúng ta sẽ tăng cường bảo mật cho trang web.

Khi nào nên dùng Persisted Queries công khai

Persisted queries là các endpoint, mỗi endpoint có URL riêng của nó, nhưng GraphQL query đã được xác định ở phía máy chủ, do đó phản hồi cũng được xác định trước (có thể trở thành động bằng cách xác định các biến, được cung cấp qua các tham số URL).

Persisted queries tương tự như các endpoint REST, nhưng chúng ta sử dụng ngôn ngữ GraphQL để soạn queries, và chúng ta có thể xuất bản trực tiếp từ wp-admin. Không cần triển khai bất kỳ mã PHP nào để xuất bản một persisted query.

Vì persisted queries không yêu cầu truyền GraphQL query trong phần body của yêu cầu, chúng phù hợp một cách tự nhiên để truy cập qua GET thay vì POST.

(Endpoint đơn và các endpoint tùy chỉnh cũng có thể được truy cập qua GET bằng cách thêm tham số ?query={ GraphQL query } vào endpoint.)

Chúng ta có thể tận dụng điều này để làm cho API nhanh hơn thông qua HTTP Caching chuẩn, lưu trữ phản hồi GraphQL ở phía máy khách hoặc các giai đoạn trung gian giữa máy khách và máy chủ (chẳng hạn như CDN).

Điều này được thực hiện thông qua extension Cache Control, tự động tính toán và xuất ra giá trị max-age của phản hồi dựa trên các trường và directive có trong query.

Nên sử dụng persisted queries bất cứ khi nào có thể, vì chúng tăng đáng kể bảo mật cho các trang web của chúng ta.

Lý do là tất cả dữ liệu cần cung cấp cho ứng dụng đều có thể được phơi bày qua persisted queries. Sau đó, chúng ta có thể bỏ qua việc phơi bày endpoint đơn GraphQL (hoặc bất kỳ endpoint tùy chỉnh nào), từ đó loại bỏ khả năng người dùng truy cập dữ liệu riêng tư mà chúng ta đã vô tình để lộ.

Khi nào nên dùng Persisted Queries riêng tư

Tương tự như các endpoint tùy chỉnh, persisted queries là CPTs, vì vậy chúng ta có thể xuất bản chúng ở chế độ private (hoặc password-protected), khiến chúng chỉ có thể truy cập được bởi những người dùng đã đăng nhập có quyền truy cập và không ai khác.

Nên sử dụng chúng bất cứ khi nào query chỉ dành cho mục đích nội bộ, chẳng hạn như khi tìm kiếm dữ liệu WordPress cho mục đích sử dụng của chính chúng ta.