Assets Proxy Middleware cho legacy assets

Trong bản cài đặt mới, một middleware đã được thêm vào để phục vụ các tệp tĩnh của trang web legacy tại đường dẫn /assets/.

Vấn đề ban đầu

Trong lịch sử, Rails Asset Pipeline phân giải các liên kết asset không trực tiếp theo vị trí tệp vật lý, mà thông qua cơ chế tìm kiếm và manifest riêng của nó. Do đó, các tệp thực tế có thể nằm trong các thư mục con khác nhau, trong khi HTML và CSS vẫn tiếp tục tham chiếu đến chúng thông qua các đường dẫn đơn giản hóa.

Trong thực tế, ít nhất các tùy chọn lưu trữ sau đã được phát hiện:

• shared/assets/ — các asset chính;
• shared/assets/stylesheets/ — CSS và các tệp liên quan;
• shared/assets/stylesheets/fonts/ — phông chữ (fonts).

Đồng thời, các liên kết từ phía client có thể trông giống như /assets/filename.css hoặc dạng tương đối url(font.woff2) mà không chỉ định thư mục con thực tế. Trong ứng dụng Rails cũ, điều này được ẩn đi bởi logic của Asset Pipeline.

Giải pháp đã thực hiện

Middleware server/middleware/assetsProxy.ts đã được thêm vào, có nhiệm vụ chặn các yêu cầu đến /assets/ và tìm kiếm tuần tự tệp được yêu cầu trong một số thư mục legacy đã biết.

Thứ tự tìm kiếm:

1. shared/assets/
2. shared/assets/stylesheets/
3. shared/assets/stylesheets/fonts/

Tệp phù hợp đầu tiên tìm thấy sẽ được trả về cho client. Do đó, hệ thống mới tái tạo lại phần cần thiết của hành vi Rails Asset Pipeline mà không cần chuyển đổi chính pipeline đó.

Bảo mật

Middleware cung cấp các giới hạn cơ bản để chống thoát khỏi thư mục asset (directory traversal):

• chặn các đường dẫn chứa ..;
• chặn dấu hai chấm trong đường dẫn;
• sau khi chuẩn hóa, kiểm tra xem đường dẫn đã phân giải có nằm bên trong shared/assets/ hay không.

Ý nghĩa đối với việc di chuyển (Migration)

Giải pháp này cho phép hiển thị chính xác các trang và kiểu dáng legacy trong thời gian chuyển đổi mà không cần viết lại thủ công một lượng lớn các liên kết asset lịch sử. Đồng thời, logic tương thích được cô lập ở một nơi và không xâm nhập vào mô hình dữ liệu cốt lõi hoặc định tuyến của haih-cms.

Kiểm tra tiếp theo

• kiểm tra các MIME type chính xác cho CSS, JS, font và hình ảnh;
• kiểm tra các header bộ nhớ đệm (cache headers);
• kiểm tra hành vi khi trùng tên tệp trong nhiều thư mục;
• đảm bảo middleware không cho phép đọc các tệp nằm ngoài cây thư mục được phép;
• khi các asset được chuẩn hóa, quyết định xem có cần proxy như một lớp vĩnh viễn hay chỉ để tương thích khi di chuyển.

Điều chỉnh kiến trúc tầng công khai

Sau khi quyết định hợp nhất dữ liệu nội dung xung quanh Concept, tác vụ kết xuất cũng được đơn giản hóa: không còn cần thiết phải tự động tái tạo một mẫu riêng cho từng loại thực thể kế thừa. Trình kết xuất Concept đa năng nên trở thành nền tảng cơ bản và các giao diện chuyên biệt chỉ được bổ sung khi có nhu cầu thực tế từ người dùng.

Điều này giúp giảm lượng mã nguồn cần bảo trì và cho phép xuất bản nội dung do AI tạo/cập nhật thông qua một cơ chế chung.

Tiến độ: Đã xây dựng xong lớp công khai của phiên bản mới

Trang web mới hiện thực sự đang chạy trên kiến trúc mới và cơ chế render phổ quát. Trong quá trình chuyển đổi, chúng tôi nhận thấy mô hình cũ tốn kém đến mức nào: các thực thể legacy khác nhau có các view riêng và trong nhiều trường hợp có các tệp CSS riêng biệt.

Việc khôi phục hoàn toàn thiết kế trực quan cho tất cả các trang nội bộ đã có chủ ý không được thực hiện. Điều đó có nghĩa là sẽ tốn thêm công sức để tái tạo các template chuyên biệt cũ, những thứ mà sau đó vẫn sẽ phải làm lại khi cập nhật thiết kế.

Ở giai đoạn hiện tại, việc hiển thị nội dung hoạt động chính xác và đồng bộ là đủ. Lần lặp lại giao diện tiếp theo nên được xây dựng dựa trên mô hình chung mới thay vì mô phỏng cấu trúc legacy.