EzyArticle cho phép quản trị viên low code bằng VS Code mà vẫn giữ được bảo mật nhờ một nguyên tắc rất rõ: mở quyền chỉnh sửa ở tầng giao diện và nội dung, nhưng không mở quyền can thiệp trực tiếp vào lõi hệ thống.
Thay vì cho người dùng sửa backend, truy cập cơ sở dữ liệu hay gọi service tùy ý, hệ thống chỉ cho họ làm việc với một cấu trúc nội dung chuẩn như page, fragment, HTML, CSS, JavaScript và một tập hàm dữ liệu đã được kiểm soát sẵn. VS Code trong mô hình này là một công cụ soạn thảo thuận tiện, không phải một cánh cửa đi thẳng vào hệ thống.

Kiến trúc tổng quát

flowchart LR
    A[Quản trị viên dùng VS Code] --> B[Extension đồng bộ nội dung]
    B --> C[Admin API có xác thực]
    C --> D[Lưu bản nháp và lịch sử thay đổi]
    D --> E[Xem trước bản mới]
    D --> F[Xuất bản có chủ đích]
    F --> G[Website public chỉ đọc bản đã publish]
Điểm mấu chốt ở đây là hệ thống tách riêng 3 giai đoạn:
  • soạn thảo
  • xem trước
  • xuất bản
Nhờ tách ba bước này, việc chỉnh sửa không tự động ảnh hưởng tới website đang chạy.

Vì sao VS Code không làm giảm bảo mật

VS Code chỉ là client, quyền thật nằm ở server

Quản trị viên dùng VS Code để sửa nội dung nhanh hơn, nhưng mọi thao tác quan trọng như đồng bộ, xem trước, xuất bản đều phải đi qua server quản trị.
Điều đó có nghĩa là:
  • server vẫn kiểm tra người dùng là ai
  • server vẫn quyết định ai được sửa gì
  • server vẫn quyết định nội dung nào được public
Nói cách khác, hệ thống không “tin” editor. Hệ thống chỉ tin các rule bảo mật ở phía server.

Không mở toàn quyền, chỉ mở một phạm vi low-code hẹp

Mô hình low-code ở đây không phải “muốn viết gì cũng được”, mà là “được chỉnh trong một khung đã định nghĩa trước”.
Ví dụ, người dùng chỉ thao tác trên các phần như:
  • nội dung chính của trang
  • phần thêm vào thẻ head
  • phần thêm trước thẻ đóng body
  • metadata mô tả trang
Cách giới hạn này giúp hệ thống giữ được tính linh hoạt cho frontend, nhưng không biến low-code thành quyền sửa toàn bộ ứng dụng.

Lớp bảo vệ thứ nhất: xác thực và phân quyền

Mọi thao tác quản trị phải đi qua lớp xác thực. Ngoài việc đăng nhập hợp lệ, hệ thống còn có thể kiểm tra vai trò và phạm vi thao tác của người dùng.
Điều đó đặc biệt quan trọng trong môi trường nhiều quản trị viên:
  • không phải ai cũng được sửa mọi nội dung
  • không phải ai cũng được publish
  • không phải ai cũng được can thiệp vào mọi khu vực giao diện
Minh hoạ đơn giản: 
flowchart TD
    A[VS Code gửi yêu cầu] --> B{Đã xác thực chưa?}
    B -- Không --> X[Từ chối]
    B -- Có --> C{Có đúng quyền không?}
    C -- Không --> Y[Từ chối]
    C -- Có --> D[Cho phép lưu / preview / publish]
Vì vậy, ngay cả khi dùng VS Code, quản trị viên vẫn chỉ làm được những gì tài khoản của họ được phép.

Lớp bảo vệ thứ hai: preview tách biệt khỏi public

Đây là một trong những điểm quan trọng nhất.
Khi quản trị viên sửa nội dung trong VS Code, thay đổi đó không lập tức hiện ra trên website public. Nó đi vào vùng nháp hoặc lịch sử thay đổi trước. Chỉ khi có hành động xuất bản rõ ràng, nội dung mới được đưa ra ngoài.
Sơ đồ này thể hiện rõ hơn:
flowchart LR
    A[Chỉnh sửa trong VS Code] --> B[Lưu bản nháp / lịch sử]
    B --> C[Xem preview nội bộ]
    B --> D[Website public]
    C --> E[Kiểm tra lại]
    E --> F[Publish]
    F --> D
Lợi ích bảo mật của cách làm này:
  • tránh làm hỏng website public chỉ vì một lần lưu file
  • tạo vùng an toàn để test trước khi phát hành
  • giảm rủi ro thao tác nhầm
  • dễ rollback hơn khi có lỗi

Lớp bảo vệ thứ ba: chỉ cho gọi dữ liệu backend qua các hàm được cấp phép

Một hệ thống low-code thường gặp rủi ro ở chỗ template có thể gọi backend quá mạnh. EzyArticle giải quyết chuyện này bằng cách không cho template truy cập backend tùy ý.
Thay vào đó, template chỉ được gọi qua một tập hàm đã được công bố trước.
Có thể hình dung như sau:
flowchart LR
    A[Template / Fragment] --> B{Hàm có nằm trong danh sách cho phép?}
    B -- Không --> X[Không được thực thi]
    B -- Có --> C[Backend trả dữ liệu an toàn]
Cách tiếp cận này có ý nghĩa rất lớn:
  • người viết low-code không gọi thẳng database
  • không chạm trực tiếp vào service nội bộ
  • không có quyền “đi lung tung” trong hệ thống
  • mọi điểm truy cập dữ liệu đều có thể kiểm soát và audit
Nói ngắn gọn, hệ thống không cho low-code quyền truy vấn tự do, mà chỉ cho gọi những capability đã được whitelist.

Lớp bảo vệ thứ tư: fragment chỉ là cơ chế ghép giao diện

EzyArticle cho phép chia giao diện thành các fragment có thể tái sử dụng. Đây là cách rất hiệu quả để low-code nhanh hơn, nhưng bản chất của fragment vẫn chỉ là thành phần view.
Fragment giúp:
  • tái sử dụng header, footer, block nội dung
  • cập nhật một nơi, nhiều trang đổi theo
  • tổ chức giao diện rõ ràng hơn
Nhưng fragment không đồng nghĩa với việc được can thiệp vào lõi ứng dụng. Nó là một cơ chế composition ở tầng hiển thị, không phải một cánh cửa để chiếm quyền backend.

Lớp bảo vệ thứ năm: có lịch sử thay đổi để audit và rollback

Mỗi lần chỉnh sửa, hệ thống có thể giữ lại lịch sử nội dung. Điều này vừa tốt cho vận hành, vừa tốt cho bảo mật.
Nếu có vấn đề xảy ra, đội ngũ có thể:
  • biết thay đổi nào vừa được tạo
  • biết thay đổi nào đã được publish
  • so sánh các phiên bản
  • quay lại trạng thái an toàn trước đó
Trong thực tế, khả năng truy vết này rất quan trọng, vì bảo mật không chỉ là “chặn truy cập sai”, mà còn là “xử lý được khi có thay đổi gây rủi ro”.

Tư duy bảo mật đằng sau thiết kế này

Có thể tóm gọn tư duy của EzyArticle thành 4 ý:
  • Không trao quyền theo công cụ, mà trao quyền theo server rule.
  • Không cho sửa trực tiếp production, mà bắt buộc đi qua preview và publish.
  • Không cho template gọi backend tự do, mà chỉ qua các hàm được kiểm soát.
  • Không mở lõi hệ thống, chỉ mở lớp giao diện đủ dùng cho low-code.
Đó là lý do vì sao hệ thống vẫn thân thiện với quản trị viên và frontend developer, nhưng không đánh đổi bằng việc nới lỏng các ranh giới bảo mật quan trọng.

Kết luận

EzyArticle an toàn khi cho phép low-code qua VS Code vì nó chọn đúng điểm để mở rộng: mở ở tầng nội dung và hiển thị, nhưng khóa chặt ở tầng quyền, dữ liệu và xuất bản.
Nói đơn giản hơn:
  • VS Code giúp làm nhanh hơn
  • preview giúp kiểm tra an toàn hơn
  • publish giúp kiểm soát chặt hơn
  • server-side permission giúp không vượt quyền
  • danh sách hàm cho phép giúp low-code không phá vỡ backend
Vì vậy, đây không phải là kiểu low-code “mở cho tiện”, mà là low-code được đặt trong một kiến trúc có ranh giới bảo mật rõ ràng.