Остановить нежелательный запрос!

Трехуровневая архитектура корпоративных приложений состоит из клиентского уровня, связующего уровня и уровня данных. Во многих J2EE-средах (Java™ 2 Platform, Enterprise Edition) связующий уровень обеспечивается сервером приложений IBM WebSphere Application Server. Сервер обрабатывает запросы от клиентского уровня и обращается к уровню данных (например, к СУБД IBM DB2®) с целью извлечения или обновления данных в соответствии с запросами клиентов и введенной ими информацией. Во многих случаях при взаимодействии с базой данных в клиентских запросах используется аутентификационный псевдоним данных. Это может привести к ослаблению строгости учета вследствие потери идентификационных сведений о вызывающей стороне. Строгость учета очень важна не только для слежения за тем, кто и что делает. Она позволяет администраторам платформы WebSphere Application Server и баз данных реагировать на такие непредвиденные события, как необходимость выявления и аннулирования нежелательных и мошеннических запросов к базе данных.

В этой статье объясняется, как использовать специальную функцию продукта WebSphere Application Server для тегирования соединений с базой данных с использованием клиентской информации, а также как применять эту функцию тегирования в таких интересующих нас ситуациях, как выявление и аннулирование мошеннических запросов.

В начало

Тегирование соединений с базой данных посредством клиентской информации

Функция, впервые появившаяся в выпуске WebSphere Application Server V6.0, позволяет тегировать соединения с базой данных посредством определенной информации. Затем эта информация передается сервером приложений на уровень базы данных (если база данных поддерживает передачу такой информации), где она может использоваться для идентификации клиента, работающего с этим соединением. Поддерживается задание следующей информации для соединения с базой данных:

• CLIENT_ACCOUNTING_INFO: Спецификация учетной информации для соединения. Эта информация используется с целью учета клиентов, преимущественно с продуктом DB2 for z/OS®.
• CLIENT_LOCATION: Спецификация местоположения клиента, инициировавшего запрос.
• CLIENT_ID: Спецификация текущего пользовательского имени для клиента данного соединения. Это имя предназначено лишь для учета клиентов и не является именем пользователя JDBC-соединения; другими словами, это не аутентификационный псевдоним данных.
• CLIENT_APPLICATION_NAME: Спецификация имени приложения, использующего соединение с базой данных.

Вышеуказанная информация для соединения может быть задана в приложении WebSphere Application Server V6.0 с помощью API-интерфейса com.ibm.websphere.rsadapter.WSConnection, показанного на рис. 2.

Начиная с выпуска WebSphere Application Server V7 значимость вышеупомянутого API-интерфейса ослабляется в пользу стандартного API-интерфейса JDBC 4.0, показанного на рис. 3.

В начало

Практическое применение функции тегирования

Предположим, ваше приложение занимается динамической компоновкой запросов к базе данных на основе пользовательских запросов, после чего направляет результирующие запросы в базу данных DB2 с помощью продукта WebSphere Application Server. В процессе тестирования вы осознаете, что для некоторых сценариев использования вам необходима возможность отклонения запросов, некорректно специфицированных клиентом. Каким образом вы могли бы сделать это?

В листинге 1 показан простой пример, исполняющий запрос к базе данных, который вы хотели бы выявить и отклонить.

.....
javax.sql.DataSource ds = (javax.sql.DataSource)ctx.lookup("jdbc/myDS"); 
conn=ds.getConnection(); 
stmt=conn.createStatement(); 
rs=stmt.executeQuery("Select * from myEmpTable");  
while(rs.next()){ 
out.println(rs.getString(1)); 

Для использования функции тегирования в данной ситуации необходимо тегировать соединения с базой данных посредством информации о клиенте. В листинге 2 показано, как это можно сделать.

import com.ibm.websphere.rsadapter.WSConnection
public void displayInfo()
{…..
Properties props = new properties();
 props.setProperty(WSConnection.CLIENT_APPLICATION_NAME,
	 "myspecialAppappname_displayInfo");

javax.sql.DataSource ds = (javax.sql.DataSource)ctx.lookup("jdbc/myDS"); 
conn=ds.getConnection(); 
((WSConnection)conn).setClientInformation(prop);
stmt=conn.createStatement(); 
rs=stmt.executeQuery("Select * from myEmpTable"); 
while(rs.next()){ 
out.println(rs.getString(1)); 
}

Теперь ваше приложение аннотирует используемое им соединение с помощью выражения myspecialAppappname_displayInfo. Теперь, когда соединение с базой данных тегировано информацией о клиенте, администратор базы данных сможет весьма просто выявить и отклонить работу, связанную с рассматриваемым приложением – ему достаточно отыскать соединения с указанным значением аннотации. К примеру, для выявления и отклонения такого запроса администратор базы данных DB2 может выполнить следующие действия:

1. В командном окне DB2 задать следующую команду для отображения всей информации о соединениях с базой данных (рис. 4):

   db2 get snapshot for applications on sample

   
   
   Рисунок 4. Команда Get snapshot
   
   
   
2. Как показано на рис. 4, параметр «TP Monitor client application name» имеет значение myspecialAppappname_displayInfo, которое было установлено вашим приложением для идентификации соединения.
3. 3. Вы можете уничтожить соединение, которое применяется для исполнения данного запроса, используя значение параметра Application handle (в данном случае 78) и выполнив соответствующую команду DB2 force application:

   db2 force application (78)

   . Эта команда прерывает соединение, исполняющее «плохой» запрос, и посылает в ваше приложение исключение типа StaleConnectionException. После этого ваше приложение должно обработать это исключение (точно так же, как и любое другое исключение типа StaleConnectionException).

Принудительное завершение «повисшего» или слишком долго исполняющегося запроса может показаться сложной задачей, однако функция тегирования WebSphere дает простой способ ее выполнения. Описанная в этой статье методика может быть применена к любой базе данных, если у этой базы данных имеются такие же, как у DB2, инструменты для отображения и отклонения определенного запроса.

Ресурсы

• Познакомьтесь с оригиналом статьи - A technique for cancelling rogue or unwanted database queries (EN)
  
  
• Информационный центр по продукту IBM WebSphere Application Server
  • Интерфейс WSConnection
  • Настройки для ввода аутентификационных данных Java 2 Connector
  
  

Об авторе

Соломан Баргути (Soloman Barghouthi) – старший инженер по программному обеспечению в лаборатории IBM в Рочестере, где он работает архитектором и руководителем группы WebSphere Application Server EJBContainer. С. Баргхути является экспертом по базам данных и автором множества статей по взаимодействию баз данных и продукта WebSphere Application Server.

Оценить эту статью

Комментарии

В начало

Содержание

• Остановить нежелательный запрос!
• Тегирование соединений с базой данных посредством клиентской информации
• Практическое применение функции тегирования
• Ресурсы
• Об авторе
• Комментарии