Tại sao Drupal cần kiến trúc đồng ý có chủ ý

Điểm mạnh của Drupal và các rủi ro đồng ý của nó đến từ cùng một nơi. Tính linh hoạt biên tập của nền tảng, quyền truy cập dựa trên vai trò và mô hình nội dung có cấu trúc chính là những gì làm cho nó trở thành lựa chọn mặc định cho các cổng thông tin chính phủ, trang web đại học và bất động sản web doanh nghiệp toàn cầu — những trang web có khả năng được kiểm tra nhất, có kho hàng thẻ của bên thứ ba đa dạng nhất được tích lũy qua nhiều năm làm việc chiến dịch, và có bề mặt cookie không thiết yếu lớn nhất để kiểm soát. Một trang Drupal 10 điển hình chạy ngăn xếp phân tích, pixel tự động hóa tiếp thị, nhúng video, biểu mẫu web với reCAPTCHA và widget chia sẻ mạng xã hội có thể gửi hơn một chục hoạt động lưu trữ không thiết yếu riêng biệt trong một lần tải trang, thường thông qua các module mà người triển khai ban đầu không còn nhớ đã cấu hình.

Mỗi hoạt động đó kích hoạt một cổng đồng ý riêng biệt. Theo Article 5(3) của Chỉ thị ePrivacy, mọi cookie không thiết yếu hoặc hoạt động lưu trữ và truy cập tương tự đều yêu cầu sự đồng ý trước, được cho tự do, cụ thể, có thông tin và không mơ hồ ở EEA, UK và bất kỳ khu vực pháp lý nào đã áp dụng cùng tiêu chuẩn. Theo GDPR, dữ liệu hành vi mà các hoạt động lưu trữ đó tạo ra là xử lý dữ liệu cá nhân vì sự kết hợp của mã định danh cookie, địa chỉ IP và dấu vết hành vi đủ để xác định một cá nhân. Câu hỏi tuân thủ trên trang Drupal do đó không phải là có cài đặt banner hay không — mọi nhóm có trách nhiệm đã làm điều đó rồi — mà là liệu banner có thực sự ngăn các thẻ kích hoạt trước khi người dùng đã đồng ý không, và liệu quyết định đồng ý có tồn tại qua các lớp bộ nhớ đệm của Drupal không.

Bức tranh module: EU Cookie Compliance, Klaro và các tùy chọn tích hợp nhà cung cấp

Module EU Cookie Compliance — module đóng góp được duy trì trên Drupal.org với tên đó — là mặc định lịch sử và tùy chọn được triển khai rộng rãi nhất. Nó đi kèm với banner có thể cấu hình, hỗ trợ các danh mục, hiển thị trạng thái đồng ý JavaScript cho mã theme trang web liên kết và lưu trữ hồ sơ đồng ý trong cơ sở dữ liệu Drupal. Điểm mạnh là tích hợp sâu với hệ thống quyền và vai trò của Drupal, hỗ trợ đa ngôn ngữ thông qua lớp dịch của Drupal và khả năng giới hạn các thẻ do Drupal tạo ra theo danh mục ở cấp độ xây dựng trang. Điểm yếu là UI của banner tụt hậu so với các tiêu chuẩn thiết kế mà các cơ quan quản lý hiện mong đợi, nhãn danh mục mặc định mơ hồ và sự tương tác của module với các lớp bộ nhớ đệm của Drupal yêu cầu cấu hình rõ ràng.

Module Klaro Cookie & Consent Management là tùy chọn gần đây hơn tích hợp thư viện Klaro JavaScript — một trình quản lý đồng ý mã nguồn mở với UI banner hiện đại và các điều khiển chi tiết theo từng dịch vụ. Điểm mạnh là chất lượng UI, độ chi tiết theo từng dịch vụ thay vì theo danh mục và phát triển upstream tích cực. Điểm yếu là module mỏng hơn EU Cookie Compliance, yêu cầu nhiều công sức tạo theme hơn và đẩy nhiều trạng thái đồng ý hơn vào phía client nơi nó phải được điều chỉnh với quá trình kết xuất phía máy chủ của Drupal.

Các tùy chọn tích hợp nhà cung cấp — Cookiebot, OneTrust, Usercentrics và tương tự — phù hợp khi trang web là một phần của một tổ chức đã chuẩn hóa theo một trong các CMP đó ở cấp độ tổ chức. Chúng thường là các tùy chọn mạnh nhất về UI và nhật ký kiểm tra nhưng giới thiệu sự phụ thuộc có tính phí của bên thứ ba và có thể yêu cầu Thỏa thuận Xử lý Dữ liệu chạy qua một quy trình mua sắm riêng biệt.

Bẫy bộ nhớ đệm đánh bại hầu hết các triển khai đồng ý Drupal

Đây là vấn đề nhấn chìm các trang Drupal được cấu hình đúng theo các khía cạnh khác: Internal Page Cache và Dynamic Page Cache, hoạt động như thiết kế, sẽ phục vụ bản kết xuất trang được lưu trong bộ nhớ đệm cho khách truy cập chưa thấy banner và bản kết xuất được lưu trong bộ nhớ đệm có thể bao gồm các thẻ script hoặc tài nguyên bên ngoài mà banner được cho là sẽ kiểm soát. Giải pháp không phải là vô hiệu hóa bộ nhớ đệm — điều đó đánh bại lý do hầu hết các doanh nghiệp chọn Drupal — mà là kết xuất các thẻ được kiểm soát đồng ý qua một đường dẫn mà các lớp bộ nhớ đệm tôn trọng.

Mẫu placeholder

Mẫu hoạt động trong môi trường sản xuất là kết xuất mỗi thẻ không thiết yếu như một placeholder trong HTML được lưu trong bộ nhớ đệm — thường là thẻ <script type="text/plain"> với thuộc tính danh mục, hoặc một phần tử tùy chỉnh mà JavaScript của module đồng ý kích hoạt chỉ ở phía client sau khi cổng liên quan đã chuyển. Chính trang Drupal có thể lưu vào bộ nhớ đệm vì placeholder giống nhau cho mọi khách truy cập; logic kích hoạt nằm trong JavaScript của module đồng ý và chạy vào thời điểm hydration so với trạng thái đồng ý theo từng khách truy cập được lưu trữ trong trình duyệt. EU Cookie Compliance hỗ trợ mẫu này ngay từ đầu; đối với Klaro tương đương là cơ chế thay thế script theo từng dịch vụ mà thư viện upstream cung cấp.

Các lớp render-cache và varnish

Cache kết xuất của Drupal và bất kỳ cache Varnish hoặc CDN upstream nào phải được cấu hình để thay đổi theo trạng thái đồng ý chỉ khi trạng thái đồng ý thay đổi HTML được kết xuất — điều này với mẫu placeholder không xảy ra. Bản thân banner được kết xuất như một khối có thể lưu vào bộ nhớ đệm riêng biệt với ngữ cảnh phân biệt giữa "cần banner" và "không cần banner", và phần còn lại của trang kết xuất giống nhau bất kể trạng thái đồng ý. Đây là lựa chọn kiến trúc làm cho các lớp bộ nhớ đệm của Drupal tương thích với việc triển khai đồng ý làm ưu tiên hàng đầu. Giải pháp thay thế — kết xuất trang khác nhau theo trạng thái đồng ý và vô hiệu hóa bộ nhớ đệm cho những người dùng đã thực hiện lựa chọn — chính là thứ tạo ra hành vi trang-chậm-sau-chấp-nhận khiến người dùng bỏ qua các banner.

Các mẫu tích hợp theo từng module

Công việc tích hợp trên trang Drupal chủ yếu là kết nối trạng thái đồng ý vào các module phát ra cookie không thiết yếu hoặc tài nguyên bên ngoài. Mẫu lặp lại trong toàn bộ hệ sinh thái module đóng góp.

• Module Google Analytics và module Google Tag Manager phải được cấu hình để kết xuất các thẻ của chúng như các placeholder được kiểm soát đồng ý, với danh mục đồng ý được ánh xạ tới cổng phân tích. Cả hai module đều hiển thị một hook mà module EU Cookie Compliance có thể kết nối.
• Module Webform với reCAPTCHA là rò rỉ tinh tế phổ biến nhất: reCAPTCHA đặt các cookie không thiết yếu khi tải ngay cả trước khi người dùng gửi biểu mẫu. Cách khắc phục là đặt thư viện reCAPTCHA sau danh mục chức năng hoặc tiếp thị có liên quan, hoặc sử dụng biến thể invisible-v3 trì hoãn việc ghi cookie cho đến khi gửi biểu mẫu.
• Nhúng video của module Media từ YouTube, Vimeo hoặc Brightcove phải sử dụng chế độ nâng cao quyền riêng tư hoặc được bọc trong một placeholder nhấp để tải trì hoãn yêu cầu của bên thứ ba cho đến khi người dùng kích hoạt nó. Mẫu Lite YouTube Embed là tương đương mà một số theme Drupal đã áp dụng.
• Widget chia sẻ mạng xã hội từ các nhà cung cấp gốc là mẫu của những năm 2010 nên được loại bỏ để ủng hộ các liên kết chia sẻ tĩnh không tải JavaScript của bên thứ ba nào cả. Nếu widget của nhà cung cấp phải ở lại, nó sẽ đứng sau cổng tiếp thị.
• Drupal Commerce và bất kỳ cookie liên quan đến giỏ hàng nào đều cần thiết tuyệt đối và không yêu cầu đồng ý, nhưng các mã định danh chương trình khách hàng thân thiết, cookie của công cụ đề xuất và các sự kiện giỏ hàng gắn liền với phân tích đòi hỏi cổng phù hợp.

Xác thực, nhật ký kiểm tra và góc độ đa ngôn ngữ

Bước xác thực trên trang Drupal là cùng một chuỗi bốn kiểm tra áp dụng ở bất kỳ đâu: một lượt truy cập không có hành động phải tạo ra không có cookie không thiết yếu nào, một lượt truy cập từ chối phải giữ nguyên trạng thái đó, một lượt truy cập chấp nhận phải tạo ra chỉ các thẻ đã đồng ý, và việc rút lại phải ngay lập tức dừng các lần kích hoạt thẻ tiếp theo và hết hạn các cookie có liên quan. Đặc biệt trên Drupal, việc xác thực này phải được thực hiện với bộ nhớ đệm trang nóng — không bỏ qua — để xác nhận rằng mẫu placeholder đang hoạt động chính xác trong các điều kiện lưu lượng thực tế.

Nhật ký kiểm tra trên Drupal được hưởng lợi từ điểm mạnh của nền tảng. EU Cookie Compliance lưu trữ các hồ sơ đồng ý trong cơ sở dữ liệu với dấu thời gian và trạng thái danh mục; Klaro có thể được cấu hình để làm tương tự qua hook phía Drupal. Cả hai đường đều tạo ra nhật ký đồng ý có thể truy vấn mà yêu cầu của cơ quan quản lý có thể được trả lời. Góc độ đa ngôn ngữ cũng quan trọng: lớp dịch của Drupal mở rộng đến văn bản banner đồng ý, vì vậy thông báo quyền riêng tư và nhãn danh mục phải được dịch cho mọi ngôn ngữ mà trang web phục vụ, và nhật ký đồng ý phải ghi lại phiên bản ngôn ngữ mà người dùng thực sự nhìn thấy. Một triển khai Drupal có thể bảo vệ vào năm 2026 là triển khai mà lựa chọn module, mẫu bộ nhớ đệm, các tích hợp theo từng module và nhật ký kiểm tra đa ngôn ngữ đều đã được xem xét cùng nhau — và nơi sự lựa chọn Drupal làm nền tảng cơ bản đã được chuyển đổi từ một trách nhiệm bộ nhớ đệm thành một lợi thế đồng ý.