Сообщений в теме: 14

[natella]

Необходимо провести нагрузочное тестировние ресурса, для доступа к которому используется HTTP Digest Access Authentication. В LoadRunner есть функция web_set_user, которая вроде бы позволяет это делать. Но в help-е очень мало информации, тем более что начала работать с программой недавно. Может кто-нибудь сталкивался с подобной проблеммой?

[Dmitry_NJ]

А в чем собственно проблема? Пока из того, что вы написали, никакой проблемы не следует.

LoadRunner поддерживает 3 типа authentication: Basic, NTLM и Digest. Когда используется Basic authentication web_set_user() функция вставляется в скрипт автоматически в процессе записи. В случае NTLM и Digest этого не происходит и вам надо ручками добавить эту функцию в ваш скрипт.

[natella]

А не найдётся ли у вас примера такого использования данной функции? Просто не совсем понятно в какое именно место скрипта её надо вставить. Заранее спасибо :)

[Dmitry_NJ]

Можете вставить ее в любое место скрипта ПЕРЕД запросом страницы, которая требует authentication. Как правило, эта функция помещается одной из первых в vuser_init() или Actions() в зависимости от того, куда вы пишете логин к серверу. А вообще определить место очень легко. Без authentication вы просто не получите запрашиваемую страницу с сервера. Поэтому смотрите на какую строчку скрипта падает ошибка при запуске и поместите web_set_user() перед ней.

[natella]

Да, это правда, мы с Леной работаем вместе )
У нас такая проблема: запрашиваемая страница (для которой нужна авторизация) имеет вид: http://host:8080/path
Как я понимаю, ф-ю надо написать так:
web_set_user ("login","password","host:8080")

После этого вызываем нужную страницу. Что должно происходить дальше? У нас приходит HTTP Status-Code=401 (Unauthorized). По идее Digest Authentication так и должно быть. После получения ответа 401 на сервер должен быть послан ещё один запрос с обработанными параметрами ответа для авторизации. Но этого не происходит. Может надо сделать что-то ещё?

[Dmitry_NJ]

После того, как вы добавили функцию web_set_user() все последующие запросы к серверу будут посылаться вместе с указанной авторизацией (username/password). Так что код возврата 401 не должен бы возвращаться. Можно еще попробовать указать первый параметр в виде domain\\username как для NTLM authentication, хотя это, наверное, врядли поможет...

Включите Еxtended log и выбирите опции Data returned by server и Advanced trace. Moжет это поможет понять в чем дело.

Кстати, никакие proxy сервера не используются для доступа к вашему сайту?

[natella]

Дело в том что сначала и должен возвращаться 401, но ответе должен содержатся заголовок типа

X-Digest realm="NAME", qop="auth", nonce="1105970946233:e39d0401b15cf98d8fa56f58a895a8945d5f4541", opaque="f48cb9156fddb2591cb56ad627e3024b1e710b82"

Это стандартный ответ для данного типа аутентификации. И в данном случае мы его получаем.
Клиент на основе полученных данных, логина и пароля проводит некоторые вычисления (тоже стандартные) и посылает на сервер ещё один запрос с этими данными в заголовке и если всё нормально приходит ответ 200.

Наверное можно каким-то образом "вручную" обработать ответ сервера и вписать запрос с полученными данными, но тогда не понятно в чём заключается поддержка LR данного вида аутентификации :rolleyes:

Кстати, после получения ответа 401 LR всё-таки посылает повторный запрос, правда опять с теми же параметрами в заголовке, что и первый и, соответственно получает тот же ответ. До того как мы вставили ф-ю web_set_user этого не происходило.
Может дело в том, как мы задаём эту функцию? Как я уже говорила, адрес нужной страницы имеет вид http://host:8080/path, а задаём мы

web_set_user ("login", "password",host:8080 )

то есть ко всему хосту, а не к нужной странице. Но весь путь прописать в функции не получается.

Прокси у нас нет, приписывание домена в юзернейме тоже ничего не изменило.

[Dmitry_NJ]

Наверное можно каким-то образом "вручную" обработать ответ сервера и вписать запрос с полученными данными, но тогда не понятно в чём заключается поддержка LR данного вида аутентификации :rolleyes:

Поддержка заключается в том, что используя LoadRunner вы можете тестировать приложения, использующие даный вид аутентификации. В чем же еще oна может заключаться? В случае Basic authentication все само запишется волшебным образом. Если вы используете что-то иное, то придется ручками поработать. В этом нет ничего страшного. Опять же не видя вашего кода сложно что-то конкретное говорить. Если у вас записался запрос к серверу, который содержит все эти страшные буквы/цифры (я имею в виду nonce и opaque), а для каждой сессии они меняются, то вам надо сделать простейшую корреляцию, чтобы заменить hard-coded values на те, которые возвращает сервер в run-time.

A функцию вы задаете правильно. Только host:port и должен там присутствовать.

[Green]

Дело в том что сначала и должен возвращаться 401, но ответе должен содержатся заголовок типа

X-Digest realm="NAME", qop="auth", nonce="1105970946233:e39d0401b15cf98d8fa56f58a895a8945d5f4541", opaque="f48cb9156fddb2591cb56ad627e3024b1e710b82"

Это стандартный ответ для данного типа аутентификации. И в данном случае мы его получаем.
Клиент на основе полученных данных, логина и пароля проводит некоторые вычисления (тоже стандартные) и посылает на сервер ещё один запрос с этими данными в заголовке и если всё нормально приходит ответ 200.
...

Кстати, после получения ответа 401 LR всё-таки посылает повторный запрос, правда опять с теми же параметрами в заголовке, что и первый и, соответственно получает тот же ответ. До того как мы вставили ф-ю web_set_user этого не происходило.

Судя по описанию, процесс выглядит следующим образом:
1. клиент -> сервер - запрос с логином и паролем пользователя
2. клиент <- сервер - ответ сервера с 401 ошибкой и кодом доступа на сервер
3. клиент -> сервер - запрос на сервер с кодом доступа

Это пример простой корреляции. Возможно, она у вас выключена или не распознается. В первом случае, включите. Во-втором, добавьте код доступа вручную.

Так же возможен вариант, что для корреляции нужен специальный файл. Его можно поискать в базе знаний на сайте Меркури. Такой файл позволяет распознавать объект корреляции автоматически. Ручная корреляция будет работать в любом случае.

[Dmitry_NJ]

Это пример простой корреляции. Возможно, она у вас выключена или не распознается. В первом случае, включите. Во-втором, добавьте код доступа вручную.

Автоматическая корреляция в процессе записи доступна только для ограниченного числа сред, например PeopleSoft, Siebel, mySAP и ряда других. Но даже специальные библиотеки для корреляции, выпущенные самими производителями, не гарантируют 100%-го результата. Свежий пример - библиотека корреляции, разработанная самим Siebel для новейшей версии своей CRM системы - Siebel 7.7.

A eсли приложение доморощенное, то про автоматическую корреляцию и говорить не приходится.

[Elena12]

Не совсем понятно, почему должна быть использована корреляция для аутентификации, если в хелпе утверждается, что достаточно функиции web_set_user(). Это первое. Во-вторых, описанный выше механизм запросов-ответов для авторизации используется и в базовой аутентификации, получается что для нее тоже нужно делать корреляцию? :blink:
Ну и третье, не совсем понятно, как, если все-таки ее использовать, достать параметры для корреляции из заголовка ответа сервера. :unsure:

[Dmitry_NJ]

Не совсем понятно, почему должна быть использована корреляция для аутентификации, если в хелпе утверждается, что достаточно функиции web_set_user().

Корреляция и аутентификация вещи в общем случае абсолютно друг с другом не связанные. Я всего лишь предположил, основываясь на ответах вашей коллеги, что может потребоваться корреляция для nonce и opaque, если они посылаются от клиента на сервер и имеют уникальные для каждой новой сессии значения. Я не видел вашего кода, не видел что именно посылает сервер клиенту, поэтому могу только предполагать в чем может заключаться проблема и как ее можно решить.

описанный выше механизм запросов-ответов для авторизации используется и в базовой аутентификации, получается что для нее тоже нужно делать корреляцию? :blink:

Может быть и нужно. Опять же корреляция никак не связана с аутентификацией. Корреляция может потребоваться сама по себе, если каждый раз когда вы прогоняете скрипт на сервер должны посылаться какие-то уникальные данные (типа session ID), которые генерируются в run-time и не могут быть параметризированы заранее.

Ну и третье, не совсем понятно, как, если все-таки ее использовать, достать параметры для корреляции из заголовка ответа сервера.  :unsure:

Здесь в двух словах не ответишь. Почитайте главу Correlating Vuser Scripts After Recording (в особенности раздел Performing Manual Correlation) в Creating Vuser Scripts user's guide. Если вы планируете заниматься нагрузочным тестированием серьезно, то без умения коррелировать записанные скрипты вам не обойтись. Не увлекайтесь автоматической корреляцией пока не набьете руку и не "прочувствуете" как это делается вручную. Тем более, что она помогает не всегда и не на 100%, так что все равно придется разбираться с тем что там автоматически "накоррелировалось".

[yurigaga]

Поищите в VUser Recoding Log window
nonce & opaque
Определите их left bound and right bound
и вставьте в script the following function

web_reg_save_param("nonce",
"LB/IC=<left bound>",
"RB/IC=r<ight bound>",
"Ord=1",
"Search=Body",
LAST);

web_reg_save_param("opaque",
"LB/IC=<left bound>",
"RB/IC=r<ight bound>",
"Ord=1",
"Search=Body",
LAST);

только перед транзакций где используются ети переменные.
И все заработает как часы

[Dmitry_NJ]

только перед транзакций где используются ети переменные.

Не перед транзакцией, где используются эти переменные (кстати, а почему вы решили, что там должна быть определена транзакция?), а перед вызовом функции, посылающей запрос, в теле ответа на который будут содержаться значения nonce и opaque. А использоваться эти переменные могут где угодно.

Да и не видя сам ответ с сервера, я бы не стал утверждать, что "Ord=1" будет работать.

[yurigaga]

Я пытался коротко обьяснить как делают manual correlation
Естественно что вариантов может быть .........

Юрий