Các lý do để niêm phong một .jar và làm thế nào để tôi xác minh điều đó?

Tôi đã tạo ra một bình kín, nhưng tôi không thấy sự khác biệt so với việc sử dụng bình không kín.

• Những xét nghiệm nào tôi có thể thực hiện để xác minh bình đã được niêm phong?
• Lý do nào chúng ta có thể phải thích sử dụng một niêm phong hơn không?
• Một niêm phong sẽ tạo ra bất kỳ rắc rối cho người dùng các dự án của tôi?

Bạn có thể kiểm tra xem một jar được niêm phong bằng cách xác định một lớp tồn tại trong một gói được sử dụng trong tệp jar. Nếu bình được niêm phong, tất cả các gói thường được niêm phong, nếu không bạn có thể niêm phong chúng trên cơ sở mỗi gói. Sau đó, lớp bạn tạo nên cố gắng truy cập các thành viên được bảo vệ hoặc mặc định của một lớp trong gói đó.

Ví dụ: nếu jar có một lớp com.example.Widgettrong đó gói com.exampleđược niêm phong và Widgetcó các thành viên được bảo vệ / mặc định, hãy tạo một lớp com.example.Testcố gắng truy cập các thành viên đó. Điều này sẽ thất bại.

Lý do niêm phong xuất phát từ một mô tả về cách kiểm tra nó: bạn muốn mã của mình được khép kín và người dùng của jar chỉ nên sử dụng các thành viên công cộng. Các gói không bắt buộc phải là duy nhất trên các lọ (và các thư mục bin trong IDE của bạn) được sử dụng bởi một chương trình. Bạn có thể định nghĩa một lớp trong cùng một gói như trong một jar và truy cập các thành viên được bảo vệ / mặc định có thể gây ra vấn đề. Thông thường, khả năng hiển thị mặc định được sử dụng như một friendtừ khóa tương tự với từ khóa của C ++ bằng cách cho phép các lớp khác trong cùng một gói khả năng thực hiện các hành động chỉ an toàn vì cùng một lập trình viên làm việc trên cả hai lớp và hiểu nội bộ của chúng. Có lẽ một phương thức hiển thị mặc định sẽ bỏ qua một số giới hạn kiểm tra tên hiệu năng, với sự hiểu rằng mã máy khách sẽ không bao giờ truy cập được. Ví dụ:Stringlớp trong Java có một vài trong số các loại phương thức này vì việc xử lý Chuỗi phải nhanh như chớp vì một lượng lớn mã phụ thuộc vào nó. BigDecimalđược xây dựng trên đầu trang BigIntegervà sử dụng quyền truy cập mặc định để tối ưu hóa một vài thao tác mà những người dùng khác của lớp không nên sử dụng.

TL; DR : Các lớp trong cùng một gói có thể truy cập các thành viên không công khai của nhau để thực hiện hoặc đơn giản. Truy cập này có thể không kiểm tra bất biến và điều kiện tiên quyết. Người ta có thể đặt các lớp trong cùng một gói ở nhiều vị trí trong đường dẫn lớp. Niêm phong một gói hoặc jar hạn chế mã máy khách truy cập các phương thức này, bởi vì nó có thể phá vỡ các công cụ khác.

Điều này sẽ không gây ra bất kỳ vấn đề cho người dùng jar. Cơ chế nạp lớp truy cập các tài nguyên (ví dụ: tệp lớp) trong các lọ hỗ trợ đầy đủ các lọ và gói kín.

Đọc liên quan: Gói niêm phong trong một tệp JAR

Để trả lời câu hỏi thứ hai của bạn, chúng tôi niêm phong các Jars của chúng tôi như một biện pháp bảo mật, vì điều này ngăn chặn một hình thức tiêm mã trong đó các lớp bổ sung được thêm vào cơ sở mã của chúng tôi trong thời gian chạy.

Chúng tôi có một lượng phản ánh nhất định trong mã của chúng tôi nơi các đối tượng được tạo dựa trên đầu vào của người dùng. Mã tạo các đối tượng này sẽ chỉ cho phép các lớp từ tên gói cố định được khởi tạo.

Bằng cách niêm phong các lọ chứa các lớp mà chúng tôi muốn người dùng có thể tạo, không có cách nào người dùng có thể tạo các lớp nguy hiểm mới và có phần mềm của chúng tôi khởi tạo chúng trong thời gian chạy. Trừ khi lớp nằm trong gói chính xác, mã của chúng tôi sẽ không tải nó và niêm phong Jars có nghĩa là chỉ các lớp chúng tôi muốn người dùng có quyền truy cập mới có thể truy cập được.

Nếu các lọ của chúng tôi không được niêm phong, người dùng có khả năng có thể thêm các lớp mới có thể được khởi tạo. Đây sẽ là một rủi ro bảo mật.

TL; DR: Bằng cách niêm phong các lọ của bạn, bạn có thể ngăn chặn một loại tiêm mã độc.