H. Giới thiệu LDAP và JNDI
4. Các vấn đề chung (và các giải pháp)
Dưới đây là hầu hết các vấn đề thông thường mà chúng ta có thể gặp phải khi biên dịch một chương trình có sử dụng các lớp JNDI.
4.1.1 Class or Package Not Found (Lớp hoặc gói không tìm thấy)
Vấn đề: Chúng ta gặp báo lỗi ―Package javax naming not found hoặc một lỗi tương tự báo các lớp còn thiếu.
Nguyên do: Chúng ta chưa nạp các lớp JNDI (jndi.jar) vào CLASSPATH của chúng ta khi chúng ta biên dịch chương trình của chúng ta, hoặc chúng ta chưa cài các lớp JNDI đúng cách như là một phần mở rộng, hoặc chúng ta quên gõ tên lớp hoặc gói.
Khắc phục: phiên bản Java 2 SDK, v1.3 bao gồm các lớp JNDI. Nếu chúng ta đang sử dụng phiên bản này và gặp lỗi do không tìm thấy một lớp hoặc gói thì hãy kiểm tra lại lần nữa xem có lỗi chính tả về các gói hoặc lớp đó không.
Nếu chúng ta hiện tại không sử dụng Java 2 SDK, v1.3 , thì chúng ta cần tải về các lớp JNDI tại http://www.java.sun.com/products/jndi/index.html và nạp chúng vào trong môi trường phát triển của chúng ta.. Cách mà chúng ta nạp các lớp JNDI tùy thuộc vào môi trường phát triển của chúng ta.
Nếu chúng ta đang sử dungj Java 2 SDK, v1.2, xin đảm bảo rằng jndi.jar được đặt trong thư mục JAVA_HOME/jre/lib/ext, JAVA_HOME là nơi chứa SDK. Nếu chúng ta đang sử dụng trình biên dịch javac từ JDK 1.1, thì thêm jndi.jar vào biến môi trường CLASSPATH của chúng ta cũng như vào tùy chọn –classpath trên dòng lệnh javac. Xem phần Những điều cần chuẩn bị để biết thêm.
4.1.2 Không tương thích với phiên bản hệ nền Java
Vấn đề: Chúng ta gặp lỗi biên dịch báo thiếu các gói hoặc các lớp java.*
Nguyên do: Chúng ta đang sử dụng phiên bản cũ của hệ nền Java.
Khắc phục: Chúng ta cần sử dụng Java 1.1.2 hoặc cao hơn. Xem http://java.sun.com/products/jdk/.
Giới Thiệu LDAP
4.2 Vấn đề về Runtime
Dưới đây là hầu hết các vấn đều thông thường mà chúng ta có thể gặp phải khi cố gắng chạy thành công việc biên dịch một chương trình có sử dụng các lớp JNDI.
4.2.1 Class Not Found (Lớp không được tìm thấy)
Vấn đề: Chúng ta gặp lỗi NoClassDefFoundError khi chạy chương trình của chúng ta.
Nguyên do: Chúng ta chưa nạp các lớp JNDI (jndi.jar) vào trong classpath của chúng ta, hoặc chúng ta chưa cài các lớp JNDI đúng cách.
Khắc phục: Java 2 SDK, v1.3 đã bao gồm các lớp JNDI vì thế nếu chúng ta đang sử dụng phiên bản này thi sẽ không mắc phải lỗi này.
Nếu hiện tại chúng ta không dùng phiên bản Java 2 SDK, v1.3 thì cách mà chúng ta nạp các lớp JNDI cho môi trường thực thi của chúng ta phụ thuộc vào môi trường. Nếu chúng ta đang sử dụng Java 2 SDK, v1.2 thì phải đảm bảo là jndi.jar nằm trong thư mục JAVA_HOME/jre/lib/ext, JAVA_HOME là nơi chứa Máy ảo Java (Java Runtime Environment – JRE). Lưu ý trên một số hệ nền, phân tách các thư mục jre/lib/ext dành cho JRE và SDK. Hãy chắc rằng JNDI JARs đã được cài đặt trong cả thư mục jre/lib/ext. Nếu chúng ta đang sử dụng thông dịch java từ JDK 1.1, thì thêm JARs vào biến môi trường CLASSPATH của chúng ta cũng như vào tùy chọn –classpath trong dòng lệnh java.
Đối với một ứng dụng ký sinh (applet), chúng ta cần chắc chắn là các lớp JNDI và các lớp cung cấp đều có giá trị với applet đó (như việc thêm vào một tùy chọn archive chẳng hạn).
4.2.2 No Initial Context (Chưa khởi tạo ngữ cảnh)
Vấn đề: Chúng ta gặp lỗi NoInititalContextException.
Nguyên do: Chúng ta chưa chỉ định việc thi công để sử dụng cho initial context. Đặc biệt, thuộc tính môi trường Context.INITIAL_CONTEXT_FACTORY chưa được thiết lập để tên lớp của hệ thống sẽ tạo initial context. Hoặc là chúng ta chưa có khả năng để lập trình các lớp của bộ cung cấp dịch vụ có tên là Context.INITIAL_CONTEXT_FACTORY.
Khắc phục: Thiết lập thuộc tính môi trường
Context.INITIAL_CONTEXT_FACTORY vào tên lớp của việc thi công initial context mà chúng ta đang sử dụng. Xem chi tiết Căn bản về JNDI.
Nếu thuộc tính đã được thiết lập, phải đảm bảo là tên lớp không bị gõ sai, và tên lớp có giá trị đối với chương trình của chúng ta (bên trong classpath của nó cũng như cài đặt trong thư mục jre/lib/ext của JRE). Java 2 SDK, v1.3 bao gồm các bộ cung cấp dịch vụ cho LDAP, COS naming, và đăng ký RMI. Tất cả các bộ cung cấp dịch vụ khác có thể được cài đặt và thêm vào trong môi trường thực thi.
4.2.3 Connection Refused (Kết nối bị từ chối)
Vấn đề: Chúng ta gặp phải lỗi CommunicationException, cho biết ―kết nối bị từ chối‖.
Nguyên do: Máy chủ và cổng được chỉ định bởi thuộc tính môi trường
ngưng kích hoạt hoặc tắt máy mà máy chủ đang chạy trên đó. Hoặc là, có thể do chúng ta gõ không đúng tên của máy chủ hoặc số cổng.
Khắc phục: Kiểm tra lại xem thực sự có một máy chủ đang chạy trên cổng đó không, và khởi động lại máy chủ nếu cần thiết. Cách mà chúng ta thực thi việc kiểm tra lệ thuộc vào máy chủ LDAP mà chúng ta đang sử dụng. Thông thường, một giao diện quản trị bằng dòng lệnh hoặc công cụ nào đó mà chúng ta có thể sử dụng để quản lý máy chủ. Chúng ta có thể sử dụng công cụ đó để phân tích trạng thái của máy chủ.
4.2.4 Connection Fails (Kết nối bị lỗi)
Vấn đề: Máy chủ LDAP phản ứng lại các tiện ích khác (như chế độ quản trị bằng dòng lênh chẳng hạn) nhưng dường như không có phản ứng đến các yêu cầu của chương trình của chúng ta.
Nguyên do: Máy chủ không phản ứng lại các yêu cầu kết nối của LDAP v3. Một số máy chủ (đặc biệt là các máy chủ công cộng) không phản ứng chính xác cho LDAP v3, phớt lờ đi các yêu cầu thay vì loại bỏ chúng. Cũng như thế, một số máy chủ LDAP v3 gặp các vấn đề trong việc kiểm soát một điều khiển mà bộ cung cấp dịch vụ LDAP của Sun gửi một cách tự động và thường trả về một đoạn code báo chỉ định máy chủ bị lỗi.
Khắc phục: Thử thiết lặp lại thuộc tính môi trường ―java.naming.ldap.version‖ thành
―2‖. Mặc định bộ cung cấp dịch vụ LDAP cố gắng thử kết nối đến một máy chủ LDAP sử dụng LDAP v3, nếu bị lỗi thì sử dụng LDAP v2. Còn nếu máy chủ phớt lờ đi một cách thầm lặng đối với yêu cầu v3, thì nhà cung cấp sẽ giả định rằng yêu cầu đã làm việc. Để công việc quay quanh máy chủ này, chúng ta phải công khai thiết lập phiên bản của nghi thức để đảm bảo hành vi trên của máy chủ là đúng.
Nếu máy chủ là máy chủ v3, thì thử thiết lập thuộc tính môi trường theo dưới đây trước khi tạo một initial context:
env.put(Context.REFERRAL, "throw");
Điều này sẽ tắt điều khiển mà nhà cung cấp LDAP gửi một cách tự động.
4.2.5 Program Hangs (Chương trình bị treo)
Vấn đề: Chương trình bị treo.
Nguyên do: Một số máy chủ (đặc biệt là các máy chủ công cộng) sẽ không phản ứng (thậm chí với một trả lời phủ định cũng không có) nếu chúng ta cố gắng thử thực hiện một tìm kiếm mà điều đó sẽ tạo ra quá nhiều kết quả hoặc điều đó sẽ yêu cầu máy chủ xem xét quá nhiều phần tử để tạo ra sự phản hồi. Các máy chủ như vậy đang cố gắng giới hạn số lượng các tài nguyên mà chúng tiêu dùng trên mỗi yêu cầu cơ bản.
Hoặc là, chúng ta cố gắng sử dụng Lớp kết nối bảo mật (Secure Socket Layer – SSL) chống lại một máy chủ/cổng mà chưa được hỗ trợ nó, và ngược lại (đó là, chúng ta cố gắng sử dụng một cổng kết nối đơn giản để giao tiếp với một cổng SSL).
Khắc phục: Nếu chương trình của chúng ta đang treo bởi vì máy chủ đang cố gắng sử dụng các tài nguyên của nó, thì việc thử lại yêu cầu của chúng ta bằng một câu truy cấn mà nó sẽ trả về một kết quả đơn hoặc chỉ một vài kết quả. Điều này sẽ giúp cho chúng ta quyết định khi nào máy chủ còn hoạt động. Nếu còn, thì chúng ta có thể mở rộng truy vấn initial của chúng ta và lại yêu cầu nó lần nữa.
Giới Thiệu LDAP Nếu chương trình của chúng ta đang treo bởi những vấn đề SSL, thì chúng ta cần phải tìm ra cổng nào là cổng SSL và kế đó thiết lập thuộc tính môi trường Context.SECURITY_PROTOCOL cho thật chính xác. Nếu cổng đó là một cổng SSL, thì thuộc tính này nên được thiết đặt lại là ―ssl‖. Nếu nó không là một cổng SSL, thì đừng thiết lập thuộc tính này.
4.2.6 Name Not Found (Tên không được tìm thấy)
Vấn đề: Chúng ta bắt gặp lỗi NameNotFoundException.
Nguyên do: Khi chúng ta khởi tạo initial context cho LDAP, chúng ta cung cấp một root- distinguished name. Ví dụ, nếu chúng ta thiết lập thuộc tính môi trường
Context.PROVIDER_URL cho initial context là
"ldap://ldapserver:389/o=JNDITutorial" và rồi cung cấp một cái tên chẳng hạn như ―cn=Tân,c=vi‖, kế đến chúng ta đưa tên đầy đủ vào dịch vụ LDAP là ―cn=Tân,c=vi,o=JNDITutorial‖ Nếu đây này cái tên mà chúng ta thực sự hướng đến, thì chúng ta nên kiểm tra lại máy chủ của chúng ta để đảm bảo rằng nó chứa một phần tử đó.
Cũng như thế, các Máy chủ thư mục SunONE và Nescape trả về lỗi này nếu chúng ta cung cấp một distinguished name không đúng cho các mục đích xác thực. Ví dụ, nhà cung cấp LDAP sẽ ném một biệt lệ NameNotFoundException nếu chúng ta thiết lập thuộc tính môi trường Context.SECURITY_PRICIPAL là "cn=Admin,o=Tutorial", và
"cn=Admin,o=Tutorial" là một phần tử không tồn tại trong máy chủ LDAP. Việc chỉnh sửa lỗi đối với các Máy chủ thư mục SunONE và Netscape để trả về chính xác những gì có liên quan đến công việc xác thực, hơn là ―name not found.‖
Khắc phục: Phân tích cái tên mà chúng ta cung cấp phải đúng là một phần tử đã có trên máy chủ. Chúng ta có thể làm điều này bằng cách liệt kết các context cha của phần tử hoặc sử dụng một số công cụ như là giao diện quản trị máy chủ thư mục bằng dòng lệnh chẳng hạn.
4.3 Vấn đề về trình duyệt
Các vấn đề dưới đây mà chúng ta có thể mắc phải khi thử triển khai một applet có sử dụng các lớp JNDI.
4.3.1 Cannot Authenticate by Using CRAM-MD5 (Không thể xác thực khi sử dụng cơ chế mã hóa CRAM-MD5)
Vấn đề: Chúng ta gặp biệt lệ AppletSecurityException khi một applet đang chạy bên trong trình duyệt Netscape cố gắng việc xác thực sử dụng mã hóa CRAM-MD5 đến máy chủ LDAP.
Nguyên do: Trình duyệt Nescape không cho truy xuất vào các gói java.security. Nhà cung cấp LDAP sử dụng chức năng mã hóa thông điệp được cung cấp bởi java.security.MessageDigest cho việc thự thi mã hóa CRAM-MD5.
Khắc phục: Sử dụng Java Plug-in (http://java.sun.com/products/plugin/).
4.3.2 Cannot Connect to Arbitrary Hosts (Không thể kết nối tùy ý đến các Host)
Vấn đề: Chúng ta gặp một biệt lệ AppletSecurityException khi applet của chúng ta cố gắng giao tiếp với một máy chủ thư mục đang chạy trên một máy khác biệt so với máy mà applet được nạp.
Nguyên do: Applet của chúng ta chưa được cho phép, vì thế nó chỉ có thể kết nối đến máy mà nó được nạp từ đó. Hoặc là, nếu applet đã được cho phép mà trình duyệt không chấp nhận việc cấp phép để applet kết nối tới một máy chủ thư mục.
Khắc phục: Nếu chúng ta muốn cho phép applet kết nối đến các máy chủ thư mục đang chạy trên các hệ thống riêng tư, thì chúng ta cần được cấp phép cho cả applet của chúng ta và cho tất cả các JNDI JARs mà applet đó đang sử dụng. Thông tin về việc
cấp phép cho jars, xem
http://java.sun.com/products/jdk/1.1/docs/guide/security/index.html.
4.3.3 Cannot Access System Properties for Configuration (Không thể truy xuất các thuộc tính hệ thống cho việc cấu hình)
Vấn đề: Chúng ta mắc phải một AppletSecurityException khi applet của chúng ta cố gắng thiết đặt các thuộc tính môi trường sử dụng các thuộc tính hệ thống.
Nguyên do: Các trình duyệt Web giới hạn việc truy xuất đến các thuộc tính của hệ thống và ném một biệt lệ là SecurityException nếu chúng ta cố gắng truy xuất chúng.
Khắc phục: Nếu chúng ta cần đưa các thông tin cho đầu vào applet của chúng ta, sao không thử sử dụng các thông số cho applet.