tomcat6 Ошибка шифрования sqlnet

Question

Недавно наследуется старая Java-кодовая база, которая использует tomcat6 с apache, и я пытаюсь настроить среду dev. Я получаю код ORA-12649 («Неизвестный алгоритм шифрования или целостности данных») при вызове DriverManager.getConnection() через внешний интерфейс входа в JSP.

Есть целый ряд вещей, которые не имеют смысла:

1. мы реализовали шифрование (с помощью настроек в slqnet.ora) на целевой БД, которая работает Oracle 11gR2, и она работает с версией производства одной и той же кодовой базы; он также работает с входящими соединениями sqldeveloper и т. д .; в основном, не было никаких проблем с реализацией шифрования на стороне db.
2. код разработки такой же, как и производственная кодовая база (на данный момент времени)
3. разработка tomcat6 такая же версия, как и производство установка
4. , если я указываю разъем на другом дб, который не реализует шифрование, авторизация успешно с действительным именем пользователя и паролем

После начитанности через Oracle документации и форумах, tomcat6 документации (в частности, свернутой, как он обрабатывает переменную CLASSPATH) У меня есть c ome up empty.

Моя догадка заключается в том, что установка tomcat6 в системе dev не ссылается на правильные файлы jar, даже если у меня есть файл ojdbc6.jar в папке установки tomcat install lib. По словам Oracle, наличие ojdbc6.jar доступного должно просто работать, когда дело доходит до реализации этого типа шифрования от тонкого клиента, каким образом это приложение tomcat реализовано.

Вот как шифрование реализуется на стороне клиента; это компилируется без ошибок:

... 
prop.setProperty(
    OracleConnection.CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_LEVEL, 
    AnoServices.ANO_REQUIRED); 
prop.setProperty(
    OracleConnection.CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_TYPES, 
    "(" + AnoServices.ENCRYPTION_AES256 + "," + 
      AnoServices.ENCRYPTION_3DES168 + "," + 
      AnoServices.ENCRYPTION_AES192 + ")"); 

// require the use of the SHA1 algorithm for data integrity checking 
prop.setProperty(
    OracleConnection.CONNECTION_PROPERTY_THIN_NET_CHECKSUM_LEVEL, 
    AnoServices.ANO_REQUIRED); 
prop.setProperty(
    OracleConnection.CONNECTION_PROPERTY_THIN_NET_CHECKSUM_TYPES, 
    "(" + AnoServices.CHECKSUM_SHA1 + ")"); 
... 

Вот соответствующие строки в файле sqlnet.ora на стороне БД, которая, как известно, работать с несколькими клиентами:

SQLNET.ENCRYPTION_SERVER=required 
SQLNET.ENCRYPTION_TYPES_SERVER=(AES256,AES192,3DES168) 
sqlnet.crypto_checksum_server=required 
sqlnet.crypto_checksum_types_server=(SHA1) 

Это дб URL быть используется в файле web.xml TOMCAT в каталоге приложения:

jdbc:oracle:thin:@<my_db_name>:1521:<my_db_sid> 

Мой файл context.xml реализует функцию «allowLinking», не уверен, если это имеет значение, но это не является стандартным, так что я» м, включая эту деталь. Это позволяет мне предоставить символическую ссылку в папке <webapps> tomcat, которая указывает на правильное местоположение в моем репо. Разрешения в каталоге - это ОК, поскольку tomcat обслуживает страницы из этого местоположения.

<Context path="/<my_app_name>" allowLinking="true"> 

Answer 1

Похоже, что ojdbc6.jar файл, указанный в CLASSPATH во время компиляции сервлета отличалась от ojdbc6.jar файла, на который ссылается tomcat6. Мое рабочее предположение заключалось в том, что содержимое любого файла с именем «ojdbc6.jar» является статическим, но, видимо, я ошибся! (Может ли кто-нибудь подтвердить, действительно ли Oracle выпускает разные версии файла с именем «ojdbc6.jar»? Я не мог найти никаких доказательств того, что они делают).

После большего количества времени, затраченного на это, я убедился, что проблема заключается в использовании версии драйвера, хотя имя файла jar было «ojdbc6.jar» для всех экземпляров. Итак, я использовал md5sum для подтверждения того, что оба файла .jar были одинаковыми, и, конечно же, они не были! Поэтому я перезагрузил ojdbc6.jar из Oracle и скопировал его в оба места, где это было необходимо, перекомпилировал мои классы сервлетов и перезапустил tomcat6. Больше ошибок при входе в зашифрованное соединение.

Похоже, что у кого-то была великая идея переименовать старую/недействительную версию файла ojdbcX.jar в ojdbc6.jar в прошлом. Я даже не хочу знать, почему. :)