2012-06-22 3 views
1

У меня есть два сервлета, которые обращаются к двум соответствующим веб-службам Axis2 на одном хосте. Один из сервлетов доступен только для чтения, а другой - в базу данных.Проблема с аутентификацией множественного соединения Axis2

Каждая веб-служба Axis2 использует аутентификацию BASIC. Веб-служба только для чтения использует системную учетную запись, а веб-служба записи использует учетные данные пользователя (которые представлены как часть веб-формы).

Проблема, с которой я столкнулся, заключается в том, что сервлет под названием второй всегда терпит неудачу при аутентификации на своем веб-сервисе. Например, я могу запросить службу только для чтения через ее сервлет, который я хочу, но при попытке использовать службу записи я получаю «401: Требуется авторизация». Если я сначала вызову службу записи, я получаю ту же ошибку, когда пытаюсь использовать службу только для чтения.

Вот как я устанавливаю учетные данные для подключения в сервлетах:

Stub service = new Stub(serviceUrl); 
HttpTransportProperties.Authenticator auth = new HttpTransportProperties.Authenticator(); 
auth.setUsername(username); 
auth.setPassword(password); 
auth.setPreemptiveAuthentication(true); 

service._getServiceClient().getOptions().setProperty(HTTPConstants.AUTHENTICATE, auth); 

сервлет, который обращается служба только для чтения имеет этот код в его конструкторе. Сервлет, который обращается к службе записи, имеет этот код в методе doGet/doPost.

Кажется, что учетные данные для первой службы называются где-то кэшированы, но я не могу найти, где это может быть. Я видел возможное решение here, но я не могу найти, где определено WSClientConstants.CACHED_HTTP_STATE. The comments in this JIRA issue, похоже, подразумевает, что это часть org.apache.axis2.transport.http.HTTPConstants, но ее там нет.

Особенности:

  • Ось версия: 1.5.1
  • Tomcat Версия: 6.0.26
  • Java Версия: 1.6.0_23

ответ

1

Оказывается, подключение к двум разные службы использовали один и тот же JSESSIONID. Таким образом, соединение со второй веб-службой пыталось использовать сеанс, прошедший проверку подлинности для первой веб-службы, вызывая ошибку.

Мое решение для этого было определение HttpClient для каждой службы, производится по следующему

MultiThreadedHttpConnectionManager manager = new MuliThreadedHttpConnectionManager(); 
HttpClient client = new HttpClient(manager); 

ConfigurationContext context = ConfigurationContextFactory.createDefaultConfigurationContext(); 
context.setProperty(HTTPConstants.CACHED_HTTP_CLIENT, client); 
context.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, true); 

Stub service = new Stub(context, serviceUrl); 

Это позволяет как сервлеты иметь отдельную сессию для своих соответствующих услуг.

0

Важным моментом является создание выделенного ConfigurationContext.

Я решил более простым способом, используя контекст конфигурации по умолчанию при создании заглушки без многопоточной фабрики соединений

окурка = новый MyStub (ConfigurationContextFactory.createDefaultConfigurationContext(), myServicesUrl);

Смежные вопросы