Статус: Новичок
Группы: Участники
Зарегистрирован: 27.01.2022(UTC)
Сообщений: 6
Сказал(а) «Спасибо»: 2 раз
|
SoapUI теперь успешно подключается, но тестовый запрос не выполняется.
Ровно так же и не выполняется тестирование подключения в 1С в панели ГИИС ДМДК.
Выдает ошибку
"Ошибка при выполнении POST-запроса по адресу /ws/v1"
Эксперементирую на копии промышленного контура по адресу *.*.*.45
Кто подскажет в чем затык?
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602  Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Автор: two_oceans  Код:accept=127.0.0.1:1500
connect=195.209.130.19:443
в hosts в 1с/browser/soapui тестируете адрес Код:http://www.goznak.ru:1500/ws/v1/exchange.wsdl
WSDL у меня браузер получил, значит имя www.goznak.ru допустимо, но дальше нежданчик в WSDL: <soap:address location="http://www.goznak.ru :80/ws/v1"/> То есть для корректной работы soapui stunnel должен слушать на 80 порту, а не на 1500. Что получаете в WSDL в строке soap:address? Возможно в ответе получили другой порт как получилось когда я пробовал?
Смысл в том, что если приложение не игнорирует, что ему прислали в WSDL, то следующий POST пойдет на адрес, указанный в soap:address. SoapUI игнорировать не должен, так как делает по стандарту.
Естественно, если stunnel на том порту не слушает, то подключитесь неизвестно к чему (если конечно вообще порт открыт). Частенько на Windows серверах порт 80 занят драйвером http.sys и если там ничего не настроено, ответ будет вроде "папка не существует" или "доступ запрещен".
Если проблема именно в номере порта, то тут возможны 3 направления решения - 1) освобождаете 80 порт от прочих приложений и слушаете стуннелом и 80 (или какой там нужен) порт тоже (просто скопируете ниже, что в конфиге после квадратных скобочек поменяв в копии имя в скобках и порт); 2) перехватываете WSDL после стуннела (например, указав в SoapUI как прокси Proxomitron) и исправляете строку (правилами проксика) на тот порт, где слушает стуннел; 3) используете приложение, которое игнорирует настройки WSDL и использует адрес из своих настроек нисмотря ни на что (думается большинство отечественных решений так поступает).
Отредактировано пользователем 18 мая 2022 г. 13:00:49(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 27.01.2022(UTC)
Сообщений: 6
Сказал(а) «Спасибо»: 2 раз
|
Автор: two_oceans Автор: two_oceans Код:accept=127.0.0.1:1500
connect=195.209.130.19:443
в hosts в 1с/browser/soapui тестируете адрес Код:http://www.goznak.ru:1500/ws/v1/exchange.wsdl
WSDL у меня браузер получил, значит имя www.goznak.ru допустимо, но дальше нежданчик в WSDL: <soap:address location="http://www.goznak.ru :80/ws/v1"/> То есть для корректной работы soapui stunnel должен слушать на 80 порту, а не на 1500. Что получаете в WSDL в строке soap:address? Возможно в ответе получили другой порт как получилось когда я пробовал?
Смысл в том, что если приложение не игнорирует, что ему прислали в WSDL, то следующий POST пойдет на адрес, указанный в soap:address. SoapUI игнорировать не должен, так как делает по стандарту.
Естественно, если stunnel на том порту не слушает, то подключитесь неизвестно к чему (если конечно вообще порт открыт). Частенько на Windows серверах порт 80 занят драйвером http.sys и если там ничего не настроено, ответ будет вроде "папка не существует" или "доступ запрещен".
Если проблема именно в номере порта, то тут возможны 3 направления решения - 1) освобождаете 80 порт от прочих приложений и слушаете стуннелом и 80 (или какой там нужен) порт тоже (просто скопируете ниже, что в конфиге после квадратных скобочек поменяв в копии имя в скобках и порт); 2) перехватываете WSDL после стуннела (например, указав в SoapUI как прокси Proxomitron) и исправляете строку (правилами проксика) на тот порт, где слушает стуннел; 3) используете приложение, которое игнорирует настройки WSDL и использует адрес из своих настроек нисмотря ни на что (думается большинство отечественных решений так поступает).
Да, все именно так. Соап успешно подключается на 1500 порт (как с хостсом так и по 127.0.0.1), а дальше ошибку выдает что не может подключиться на тот же адрес но по 80 порту. Ну да ну да, уровень танцев с бубном выходит на запредельный уровень - теперь мы будем освобождаться 80 порт от системных процессов. Выхода не видно?
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Автор: dubinin.nik Ну да ну да, уровень танцев с бубном выходит на запредельный уровень - теперь мы будем освобождаться 80 порт от системных процессов. Выхода не видно? Для начала занят ли он? Проверить можно командой наподобие такой: netstat -a -n | findstr :80 и в худшем случае ответ будет вроде такого: TCP 0.0.0.0:80 0.0.0.0:0 LISTENING То есть слушает порт 80 на всех адресах. Если слушает не на всех адресах, то вероятно 127.0.0.x:80 уже свободен. Если на всех, то дальше выяснять кто слушает. Если обычные программы - можно что-то подвинуть, например, сузить список адресов. Если системный процесс, то там выловить сложно кто конкретно слушает, проще все же установить проксик между соапуи и стуннелом и поменять номер порта. Как вариант, можно использовать старую серверную операционку (или виртуальную машину с ней), на которой еще не было такого уклона к web в каждой роли сервера - чисто для размещения стуннела. На 2008R2 сервере у меня порт 80 свободен (доменный УЦ передвинут, но даже без http списки отзыва доступны по LDAP). Отредактировано пользователем 30 мая 2022 г. 13:45:25(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 02.07.2024(UTC) Сообщений: 1
|
Тема та же, настраиваю интеграцию с ГИИС, делал это уже не раз, вот только на одном компе не как не получается, не пойму в чём проблема. Настройки все те же, что и у втора темы. Только ошибка другая. Код:2024.07.02 15:16:23 LOG7[1344:10308]: Creating a new thread
2024.07.02 15:16:23 LOG7[1344:10308]: New thread created
2024.07.02 15:16:23 LOG7[1344:2632]: client start
2024.07.02 15:16:23 LOG7[1344:2632]: https started
2024.07.02 15:16:23 LOG7[1344:2632]: FD 352 in non-blocking mode
2024.07.02 15:16:23 LOG7[1344:2632]: TCP_NODELAY option set on local socket
2024.07.02 15:16:23 LOG5[1344:2632]: https connected from 127.0.0.1:52796
2024.07.02 15:16:23 LOG7[1344:2632]: FD 356 in non-blocking mode
2024.07.02 15:16:23 LOG7[1344:2632]: https connecting
2024.07.02 15:16:23 LOG7[1344:2632]: connect_wait: waiting 10 seconds
2024.07.02 15:16:23 LOG7[1344:2632]: connect_wait: connected
2024.07.02 15:16:23 LOG7[1344:2632]: Remote FD=356 initialized
2024.07.02 15:16:23 LOG7[1344:2632]: TCP_NODELAY option set on remote socket
2024.07.02 15:16:23 LOG7[1344:2632]: start SSPI connect
2024.07.02 15:16:23 LOG5[1344:2632]: try to read the client certificate
2024.07.02 15:16:23 LOG7[1344:2632]: open file c:\stunnel\clicer.cer with certificate
2024.07.02 15:16:23 LOG3[1344:2632]: Credentials complete
2024.07.02 15:16:23 LOG7[1344:2632]: 321 bytes of handshake data sent
2024.07.02 15:16:23 LOG5[1344:2632]: 7 bytes of handshake(in handshake loop) data received.
2024.07.02 15:16:23 LOG3[1344:2632]: **** Error 0x80090326 returned by InitializeSecurityContext (2)
2024.07.02 15:16:23 LOG3[1344:2632]: Error performing handshake
2024.07.02 15:16:23 LOG5[1344:2632]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2024.07.02 15:16:23 LOG7[1344:2632]: free Buffers
2024.07.02 15:16:23 LOG7[1344:2632]: delete c->hContext
2024.07.02 15:16:23 LOG7[1344:2632]: delete c->hClientCreds
2024.07.02 15:16:23 LOG5[1344:2632]: incomp_mess = 0, extra_data = 0
2024.07.02 15:16:23 LOG7[1344:2632]: https finished (0 left)
Отредактировано пользователем 2 июля 2024 г. 10:39:55(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники
Зарегистрирован: 16.04.2008(UTC)
Сообщений: 1,341
Сказал(а) «Спасибо»: 25 раз
Поблагодарили: 510 раз в 361 постах
|
Автор: Agenial 2024.07.02 15:16:23 LOG3[1344:2632]: **** Error 0x80090326 returned by InitializeSecurityContext (2) При SEC_E_ILLEGAL_MESSAGE и вообще всегда полезно глянуть в системный журнал - там могут быть дополнительные детали по ошибке. |
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
