Thư Viện Câu Hỏi Phỏng Vấn

Khi làm việc với ORM như Entity Framework Core, việc truy vấn dữ liệu có mối quan hệ (Relationships như One-to-Many, Many-to-Many) đòi hỏi lập trình viên phải hiểu rõ các chiến lược tải dữ liệu liên quan.

Extension Methods (Phương thức mở rộng) là một tính năng mạnh mẽ của ngôn ngữ C# cho phép lập trình viên thêm các phương thức mới vào các kiểu dữ liệu đã tồn tại mà không cần tạo lớp kế thừa mới, không cần biên dịch lại mã nguồn gốc của kiểu dữ liệu đó.

Trong Reactive Programming, khi một lỗi xảy ra trong một Observable, luồng dữ liệu sẽ bị kết thúc (terminate) ngay lập tức. Để ngăn chặn việc này, toán tử catchError cần được đặt ngay sau toán tử thực hiện tác vụ bất đồng bộ (như switchMap hoặc mergeMap) thay vì đặt ở cuối chuỗi. Việc đặt catchError bên trong phạm vi của toán tử xử lý sẽ giúp cô lập lỗi, cho phép luồng chính tiếp tục hoạt động mà không bị ngắt kết nối. Ví dụ: source$.pipe(switchMap(val => apiCall(val).pipe(catchError(err => of(fallbackValue))))) giúp đảm bảo nếu apiCall thất bại, chỉ có yêu cầu đó bị ảnh hưởng và trả về giá trị mặc định, thay vì làm chết toàn bộ Subscription.

Việc gọi thủ công unsubscribe() dễ dẫn đến sai sót nếu lập trình viên quên thực hiện trong các Hook như ngOnDestroy hoặc componentWillUnmount, gây ra Memory Leak. Toán tử takeUntil cho phép chúng ta khai báo một Observable 'notifier' (thường là một Subject). Khi notifier này phát ra giá trị, tất cả các Subscription liên kết sẽ tự động bị hủy. Cách tiếp cận này mang tính khai báo (declarative), giúp code sạch hơn, dễ bảo trì và đảm bảo tính nhất quán trong việc quản lý tài nguyên, đặc biệt khi một Component có nhiều Subscription cần được dọn dẹp cùng một lúc.

Toán tử exhaustMap hoạt động theo cơ chế: khi nhận được một giá trị từ nguồn, nó sẽ bắt đầu xử lý tác vụ đó và bỏ qua (ignore) tất cả các giá trị mới từ nguồn cho đến khi tác vụ hiện tại hoàn thành. Trong nghiệp vụ Enterprise, khi người dùng nhấn nút 'Submit' nhiều lần liên tiếp, exhaustMap đảm bảo rằng chỉ có yêu cầu đầu tiên được xử lý, các lần nhấn sau đó sẽ bị loại bỏ cho đến khi server phản hồi. Điều này giúp tránh tình trạng gửi trùng lặp dữ liệu (duplicate submission) mà không cần phải quản lý trạng thái 'isSubmitting' thủ công bằng biến boolean.

Toán tử map chỉ đơn thuần là biến đổi giá trị (giống như Array.prototype.map), nó trả về giá trị trực tiếp. Ngược lại, mergeMap được dùng để xử lý các tác vụ bất đồng bộ (Inner Observable), nó sẽ tự động subscribe vào Observable được trả về và 'flatten' (làm phẳng) kết quả vào luồng chính. Lỗi phổ biến của Junior là sử dụng map để gọi một hàm trả về Observable, dẫn đến việc nhận được một Observable lồng nhau (Observable<Observable>) thay vì giá trị thực tế. Để lấy dữ liệu từ các tác vụ bất đồng bộ, bắt buộc phải dùng các toán tử dạng *Map như mergeMap, switchMap hoặc concatMap.

AsyncSubject có đặc điểm chỉ phát ra giá trị cuối cùng của chuỗi dữ liệu sau khi Observable hoàn thành (complete). Trong kiến trúc Enterprise, nó rất hữu ích khi cần thực hiện một chuỗi các tác vụ khởi tạo (ví dụ: tải cấu hình, xác thực người dùng, lấy thông tin profile) và chỉ muốn thông báo cho các thành phần khác khi tất cả đã hoàn tất. Khi các thành phần khác subscribe vào AsyncSubject sau khi nó đã hoàn thành, chúng sẽ nhận được giá trị cuối cùng đó ngay lập tức. Lưu ý: Nếu AsyncSubject không được gọi complete(), nó sẽ không phát ra bất kỳ giá trị nào, đây là điểm cần kiểm soát chặt chẽ trong luồng logic.

Bản chất vấn đề

Rate Limiting là kỹ thuật kiểm soát tần suất yêu cầu (request) mà một client có thể gửi đến server trong một khoảng thời gian nhất định. Trong môi trường Enterprise, đây là lớp phòng thủ đầu tiên chống lại các cuộc tấn công Brute Force, DoS (Denial of Service) và ngăn chặn việc lạm dụng API (API abuse).

Tác động bảo mật

Khi ứng dụng trả về các thông báo lỗi chi tiết (như Stack Trace, đường dẫn file, tên bảng database, hoặc phiên bản framework), kẻ tấn công có thể thu thập thông tin về cấu trúc hệ thống để lập kế hoạch tấn công chính xác hơn (Reconnaissance).

Cơ chế hoạt động

Content Security Policy (CSP) là một HTTP header cho phép quản trị viên website kiểm soát các tài nguyên (scripts, styles, images) mà trình duyệt được phép tải từ các nguồn đáng tin cậy. CSP ngăn chặn việc thực thi các đoạn mã độc hại ngay cả khi kẻ tấn công đã chèn được script vào trang web.

Phân tích kiến trúc

1. In-memory (Session mặc định): Dữ liệu lưu trên RAM của server. Khi server khởi động lại hoặc scale-out (thêm server mới), session sẽ bị mất hoặc không đồng bộ giữa các server.
2. Redis (External Store): Dữ liệu lưu trữ tập trung. Tất cả các instance của ứng dụng đều truy cập vào cùng một nguồn dữ liệu session.

Tại sao Redis an toàn hơn?

• Tính nhất quán: Đảm bảo người dùng không bị đăng xuất khi hệ thống tự động scale.
• Bảo mật: Redis có thể được cấu hình với mật khẩu và chỉ cho phép truy cập từ mạng nội bộ (VPC).
• Hiệu năng: Redis hoạt động dựa trên RAM nên tốc độ đọc/ghi cực nhanh, đáp ứng tiêu chuẩn Enterprise.

Lưu ý

Luôn mã hóa dữ liệu nhạy cảm trước khi lưu vào Redis và sử dụng kết nối TLS để bảo mật dữ liệu trên đường truyền giữa ứng dụng và Redis server.

Tại sao Client-side validation là không đủ?

Client-side validation (sử dụng JavaScript hoặc HTML5 attributes) chỉ nhằm mục đích cải thiện trải nghiệm người dùng (UX). Kẻ tấn công có thể dễ dàng bỏ qua bằng cách sử dụng Postman, cURL hoặc can thiệp trực tiếp vào trình duyệt để gửi dữ liệu độc hại trực tiếp đến server.

Phân tích bản chất

Giải pháp kỹ thuật

Tại sao Singleton là Anti-pattern?