Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

16 Страницы«<1112131415>»
Опции
К последнему сообщению К первому непрочитанному
Offline ARnikev  
#121 Оставлено : 30 июня 2015 г. 11:42:38(UTC)
ARnikev

Статус: Активный участник

Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Автор: Bpar Перейти к цитате
Еще офтоп

Автор: Inviz Перейти к цитате

Я добавил еще один импорт в типы и все сгенирилось через wsimport нормально

<wsdl:types>
<xsd:schema targetNamespace="http://roskazna.ru/gisgmp/02000000/SmevGISGMPService/" xmlns:smev="http://smev.gosuslugi.ru/rev120315">
<xsd:import schemaLocation="xsd/request/smev.unifo.rev120315.xsd" namespace="http://smev.gosuslugi.ru/rev120315"/>
<xsd:import schemaLocation="xsd/request/Message.xsd" namespace="http://roskazna.ru/gisgmp/xsd/116/Message"/>
<xsd:element name="GISGMPTransferMsg" type="smev:BaseMessageType"/>
</xsd:schema>
</wsdl:types>



При попытке импорта xsd схем выдается ошибка

wsdl.exe /language:cs SmevGISGMPService.wsdl
Ошибка. Не удается импортировать привязку "SmevGISGMPServiceSOAP" из пространства имен "http://roskazna.ru/gisgmp/0
2000000/SmevGISGMPService/".
- Не удается импортировать операцию "GISGMPTransferMsg".
- Отсутствует тип данных "http://smev.gosuslugi.ru/rev120315:BaseMessageType".

Архив со схемами распакован в тот-же каталог с сохранением иерархии каталогов.
Что делать, подскажите.


Импорта куда? Что вы из этих схем хотите получить? Если просто классы, то скачайте архив с подправленным wsdl и схемами, что я выкладывал несколькими страницами выше. С помощью apache cxf (http://cxf.apache.org/docs/wsdl-to-java.html) получите из wsdl корректный набор классов. Если хотите клиент к вебсервису сгенерить, то тут не помогу.
Offline Bpar  
#122 Оставлено : 30 июня 2015 г. 12:42:59(UTC)
Bpar

Статус: Участник

Группы: Участники
Зарегистрирован: 05.08.2014(UTC)
Сообщений: 12

Поблагодарили: 2 раз в 2 постах
Автор: ARnikev Перейти к цитате

Импорта куда? Что вы из этих схем хотите получить? Если просто классы, то скачайте архив с подправленным wsdl и схемами, что я выкладывал несколькими страницами выше. С помощью apache cxf (http://cxf.apache.org/docs/wsdl-to-java.html) получите из wsdl корректный набор классов. Если хотите клиент к вебсервису сгенерить, то тут не помогу.


Дело в том, что и Ваш архив и оригинальный wsdl генерят только некоторые классы. Вот что пишет техподдержка:
В xsd схеме форматов 1.16 отсутствуют ссылки на данные xsd как в форматах 1.15 и соответственно автоматически не подтянуться..
Например, в xsd-схемах есть BudgetIndex, Charge и др., а в результирующем коде и классах, генерируем wsdl их нет.
Offline ARnikev  
#123 Оставлено : 30 июня 2015 г. 13:18:36(UTC)
ARnikev

Статус: Активный участник

Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Автор: Bpar Перейти к цитате
Автор: ARnikev Перейти к цитате

Импорта куда? Что вы из этих схем хотите получить? Если просто классы, то скачайте архив с подправленным wsdl и схемами, что я выкладывал несколькими страницами выше. С помощью apache cxf (http://cxf.apache.org/docs/wsdl-to-java.html) получите из wsdl корректный набор классов. Если хотите клиент к вебсервису сгенерить, то тут не помогу.


Дело в том, что и Ваш архив и оригинальный wsdl генерят только некоторые классы. Вот что пишет техподдержка:
В xsd схеме форматов 1.16 отсутствуют ссылки на данные xsd как в форматах 1.15 и соответственно автоматически не подтянуться..
Например, в xsd-схемах есть BudgetIndex, Charge и др., а в результирующем коде и классах, генерируем wsdl их нет.


С оригинального генерятся не все классы, это правда, а вот с архива, который я выкладывал, все генерится корректно. Вроде как товарищ afev его же использовал для генерации классов. Наверное что-то не так делаете.
Offline belgampaul  
#124 Оставлено : 30 июня 2015 г. 17:20:31(UTC)
belgampaul

Статус: Новичок

Группы: Участники
Зарегистрирован: 25.06.2015(UTC)
Сообщений: 8

Поблагодарили: 2 раз в 1 постах
Автор: belgampaul Перейти к цитате
Автор: ARnikev Перейти к цитате
Автор: belgampaul Перейти к цитате

Все выяснили наконец-то. Службе поддержки как обычно незачет. 2 дня ждать от них ответ, чтобы они еще раз прислали DigestValue, а не сущность, которую проверяли.
Обошлись без службы поддержки. Подписываемая сущность у нас верная. Точнее Digest ее верен. Но подписываем мы не одновременно с отправлением. Сначала подписываем. Потом на другом статусе документ выгружаем. А JAXB, если его не научить, каждый раз может новые префиксы придумывать. В итоге получается картина, что Digest верный для нас, но данные изменились.

В итоге: и сущность, которую подписываем и сущность, которую передаем в soap пакете должны быть идентичны.


Что значит на другом статусе документ выгружаете? Вы убедились что ошибка в этом, удалось в итоге импортировать что-то корректно на тестовый сервис?
Я только что проверил у себя, у меня все префиксы и сущность в целом остается неизменной, что до подписи, что после, что перед самой отправкой сообщения в ГИС ГМП...


>>Что значит на другом статусе документ выгружаете?
Это значит, что сущность подписывается на одном статусе, а пакет отправляется на другом. В пакете раньше пространства имен в сущности могли отличаться от тех, что были использованы при подписании, т.к. jaxb по-умолчанию сам выбирает префиксы.

Выгрузить пока не удалось.
Что удалось выяснить, так это-то, что код в архиве с первой страницы содержит ошибку. Во всяком случае DigestValue, для сущности неправильно генерит с корректного примера.
Но для нас эта проблема неактуальна. Система использует нативный КриптоПро провайдер.


Все. Выгрузилось без ошибки.
Краткое содержание наших крупных ошибок:
1. Для DigestValue генерировался неправильный хэш, т.к. данные приходили для подписи в кодировке UTF-16LE.
2. После исправления п. 1. DigestValue был неверным из-за отличающихся пространств имен в сущности и той же сущности в пакете.
3. После исправления п. 2. SignatueValue был неверным (подпись сама). Это был самая тяжелая ошибка. Суть ее описана http://www.cryptopro.ru/....aspx?g=posts&t=6288
Коротко: результат хэша нужно инвертировать побайтно.

Если кому понадобится, могу выложить xml с запросом на импортом и сертификат с закрытым ключом для ЭП-СП, чтобы была возможность контролировать правильность вычислений поэтапно.
Ну и библиотеку могу выложить сгенеренную с wsdl. Там правда неймспейсы подкорректированы.

Отредактировано пользователем 30 июня 2015 г. 17:22:06(UTC)  | Причина: Не указана

Offline Евгений Афанасьев  
#125 Оставлено : 30 июня 2015 г. 17:48:53(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,910
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 685 раз в 646 постах
Если не сложно, выложите, могут пригодиться.
Offline belgampaul  
#126 Оставлено : 30 июня 2015 г. 18:18:30(UTC)
belgampaul

Статус: Новичок

Группы: Участники
Зарегистрирован: 25.06.2015(UTC)
Сообщений: 8

Поблагодарили: 2 раз в 1 постах
Автор: afev Перейти к цитате
Если не сложно, выложите, могут пригодиться.


2015_06_30_22_01_19_271_request.txt (8kb) загружен 33 раз(а). 2015_06_30_22_01_23_535_response.txt (13kb) загружен 19 раз(а). EPSPGISGMP.pfx.txt (2kb) загружен 20 раз(а). 2015_06_30_22_01_13_415_response.txt (12kb) загружен 18 раз(а). 2015_06_30_22_01_07_546_request.txt (17kb) загружен 26 раз(а).
Файлики приаттачил (запрос иморта платежа -> ответ; запрос статуса запроса -> ответ). Сертификат и закрытый ключ.Расширение txt убираете и импортируете. ГИС ГМП ответит ошибкой, что УИП некорректный, но это совсем другая история )

Отредактировано пользователем 1 июля 2015 г. 1:29:50(UTC)  | Причина: Не указана

thanks 2 пользователей поблагодарили belgampaul за этот пост.
ufz49107@cdnqa.com оставлено 23.07.2015(UTC), InkvizitorZ оставлено 18.08.2015(UTC)
Offline ARnikev  
#127 Оставлено : 1 июля 2015 г. 9:10:59(UTC)
ARnikev

Статус: Активный участник

Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Автор: belgampaul Перейти к цитате

Все. Выгрузилось без ошибки.
Краткое содержание наших крупных ошибок:
1. Для DigestValue генерировался неправильный хэш, т.к. данные приходили для подписи в кодировке UTF-16LE.
2. После исправления п. 1. DigestValue был неверным из-за отличающихся пространств имен в сущности и той же сущности в пакете.
3. После исправления п. 2. SignatueValue был неверным (подпись сама). Это был самая тяжелая ошибка. Суть ее описана http://www.cryptopro.ru/....aspx?g=posts&t=6288
Коротко: результат хэша нужно инвертировать побайтно.

Если кому понадобится, могу выложить xml с запросом на импортом и сертификат с закрытым ключом для ЭП-СП, чтобы была возможность контролировать правильность вычислений поэтапно.
Ну и библиотеку могу выложить сгенеренную с wsdl. Там правда неймспейсы подкорректированы.


Можно про 2 пункт по-подробней, пожалуйста? Что значит сущности и сущности в пакете? Можно с примером?
По поводу 3 пункта, вы какой библиотекой подписываете? Примером что afev выложил? На сколько я понимаю, для этого примера эта ошибка не актуальна, т.к. у меня при формировании запроса полностью руками, подпись сервисом проверяется корректно, не работает только при формировании запроса с помощью классов, полученных из wsdl сервиса?
Можете выложить классы, которые вы получили с подкорректированного wsdl и кусок кода, который формирует сообщение?




Offline belgampaul  
#128 Оставлено : 1 июля 2015 г. 23:27:47(UTC)
belgampaul

Статус: Новичок

Группы: Участники
Зарегистрирован: 25.06.2015(UTC)
Сообщений: 8

Поблагодарили: 2 раз в 1 постах
gisgmp_1.16.1.jar.txt (143kb) загружен 17 раз(а).
Автор: ARnikev Перейти к цитате

Можно про 2 пункт по-подробней, пожалуйста? Что значит сущности и сущности в пакете? Можно с примером?
По поводу 3 пункта, вы какой библиотекой подписываете? Примером что afev выложил? На сколько я понимаю, для этого примера эта ошибка не актуальна, т.к. у меня при формировании запроса полностью руками, подпись сервисом проверяется корректно, не работает только при формировании запроса с помощью классов, полученных из wsdl сервиса?
Можете выложить классы, которые вы получили с подкорректированного wsdl и кусок кода, который формирует сообщение?

По 2 пункту уже выше писал. Еще раз повторюсь, значит. Пользователь подписывает документ стандартно в системе. В системе документы отличаются от тех, что мы выгружаем по нескольким (дополнительным) полям. Но подписывает пользователь по факту не документ системы, а сущность, которую отправит позднее. Т.е. в момент подписания, мы из документа собираем сущность и подписываем. Подпись храним в БД. Далее пользователь доводит документ до статуса Готов к выгрузке. Как только выбирает действие Выгрузить, сущность собирается заново. Точнее даже не только сущность собирается, а целиком запрос GISGMPTransferMsg. Если жестко не прописать в package-info.java префиксы для неймспейсов, то существует высокая вероятность, что префиксы будут отличаться от тех, что были сформированы для сущности, которую подписывали. Просто так написана система. Далее мы отправляем пакет. При отправке пакета подписей вообще нет. Их мы и вставляем в хэндлерах. Сначала подпись сущности достаем из базы (ds:Signature), потом уже весь пакет подписываем. Т.к. подпись подпихивали в уже сформированный soap документ, то несовпадение неймспейсов приводило к невалидности.

По п.3: подписывает КриптоПро через нативный код. Ему Java прокидывает канонизированный SignedInfo в виде бинарного массива.
Что касается куска кода, который формирует сообщение, то этим вопросом занимается JAX-WS на пару с JAXB. Я только передаю BaseMessage (что-то типа port.transferMsg(baseMessage)). Дальше как выше описал, отрабатывает хэндлер, смысл которого подпихнуть подпись сущности и затем наложить ЭП-ОВ.

Сгенеренную библиотеку выложу как только смогу. Завтра точно. Имейте в виду, что префиксы неймспейсов там жестко прописаны. Могу и исходники в личку бросить. Библиотеку можно юзать как есть, там ничего лишнего нет.

Отредактировано пользователем 2 июля 2015 г. 13:41:58(UTC)  | Причина: Не указана

Offline ARnikev  
#129 Оставлено : 2 июля 2015 г. 9:24:18(UTC)
ARnikev

Статус: Активный участник

Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Автор: belgampaul Перейти к цитате
Автор: ARnikev Перейти к цитате

Можно про 2 пункт по-подробней, пожалуйста? Что значит сущности и сущности в пакете? Можно с примером?
По поводу 3 пункта, вы какой библиотекой подписываете? Примером что afev выложил? На сколько я понимаю, для этого примера эта ошибка не актуальна, т.к. у меня при формировании запроса полностью руками, подпись сервисом проверяется корректно, не работает только при формировании запроса с помощью классов, полученных из wsdl сервиса?
Можете выложить классы, которые вы получили с подкорректированного wsdl и кусок кода, который формирует сообщение?

По 2 пункту уже выше писал. Еще раз повторюсь, значит. Пользователь подписывает документ стандартно в системе. В системе документы отличаются от тех, что мы выгружаем по нескольким (дополнительным) полям. Но подписывает пользователь по факту не документ системы, а сущность, которую отправит позднее. Т.е. в момент подписания, мы из документа собираем сущность и подписываем. Подпись храним в БД. Далее пользователь доводит документ до статуса Готов к выгрузке. Как только выбирает действие Выгрузить, сущность собирается заново. Точнее даже не только сущность собирается, а целиком запрос GISGMPTransferMsg. Если жестко не прописать в package-info.java префиксы для неймспейсов, то существует высокая вероятность, что префиксы будут отличаться от тех, что были сформированы для сущности, которую подписывали. Просто так написана система. Далее мы отправляем пакет. При отправке пакета подписей вообще нет. Их мы и вставляем в хэндлерах. Сначала подпись сущности достаем из базы (ds:Signature), потом уже весь пакет подписываем. Т.к. подпись подпихивали в уже сформированный soap документ, то несовпадение неймспейсов приводило к невалидности.

По п.3: подписывает КриптоПро через нативный код. Ему Java прокидывает канонизированный SignedInfo в виде бинарного массива.
Что касается куска кода, который формирует сообщение, то этим вопросом занимается JAX-WS на пару с JAXB. Я только передаю BaseMessage (что-то типа port.transferMsg(baseMessage)). Дальше как выше описал, отрабатывает хэндлер, смысл которого подпихнуть подпись сущности и затем наложить ЭП-ОВ.

Сгенеренную библиотеку выложу как только смогу. Завтра точно. Имейте в виду, что префиксы неймспейсов там жестко прописаны. Могу и исходники в личку бросить. Библиотеку можно юзать как есть, там ничего лишнего нет.





Ясно, у вас все сложно как-то). У нас вроде нет такого рода проблем. Спасибо за пояснения.
Offline Inviz  
#130 Оставлено : 2 июля 2015 г. 10:47:45(UTC)
Inviz

Статус: Участник

Группы: Участники
Зарегистрирован: 04.06.2015(UTC)
Сообщений: 10

Поблагодарили: 1 раз в 1 постах
Автор: Bpar Перейти к цитате
Еще офтоп

Автор: Inviz Перейти к цитате

Я добавил еще один импорт в типы и все сгенирилось через wsimport нормально

<wsdl:types>
<xsd:schema targetNamespace="http://roskazna.ru/gisgmp/02000000/SmevGISGMPService/" xmlns:smev="http://smev.gosuslugi.ru/rev120315">
<xsd:import schemaLocation="xsd/request/smev.unifo.rev120315.xsd" namespace="http://smev.gosuslugi.ru/rev120315"/>
<xsd:import schemaLocation="xsd/request/Message.xsd" namespace="http://roskazna.ru/gisgmp/xsd/116/Message"/>
<xsd:element name="GISGMPTransferMsg" type="smev:BaseMessageType"/>
</xsd:schema>
</wsdl:types>



При попытке импорта xsd схем выдается ошибка

wsdl.exe /language:cs SmevGISGMPService.wsdl
Ошибка. Не удается импортировать привязку "SmevGISGMPServiceSOAP" из пространства имен "http://roskazna.ru/gisgmp/0
2000000/SmevGISGMPService/".
- Не удается импортировать операцию "GISGMPTransferMsg".
- Отсутствует тип данных "http://smev.gosuslugi.ru/rev120315:BaseMessageType".

Архив со схемами распакован в тот-же каталог с сохранением иерархии каталогов.
Что делать, подскажите.

BaseMessageType содержится в xsd/request/smev.unifo.rev120315.xsd
Я генерил через wsimport


Не могу выложить архив - на работе запрещена загрузка файлов.
Опишу устно..
Берем форматы http://www.roskazna.ru/g...0%9C%D0%9F%201_16_1.docx
В документе на последней странице wsdl и архив с XSD
WSDL сохраняем в файл, редактируем.
Получается так
Код:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:unifo="http://roskazna.ru/gisgmp/02000000/SmevGISGMPService/" name="SmevGISGMPService" targetNamespace="http://roskazna.ru/gisgmp/02000000/SmevGISGMPService/">
	<wsdl:types>
		<xsd:schema targetNamespace="http://roskazna.ru/gisgmp/02000000/SmevGISGMPService/" xmlns:smev="http://smev.gosuslugi.ru/rev120315">
			<xsd:import schemaLocation="xsd/request/smev.unifo.rev120315.xsd" namespace="http://smev.gosuslugi.ru/rev120315"/>
			<xsd:import schemaLocation="xsd/request/Message.xsd" namespace="http://roskazna.ru/gisgmp/xsd/116/Message"/>
			<xsd:element name="GISGMPTransferMsg" type="smev:BaseMessageType"/>
		</xsd:schema>
	</wsdl:types>
	<wsdl:message name="GISGMPTransferMsgRequest">
		<wsdl:part name="inputmsg" element="unifo:GISGMPTransferMsg"/>
	</wsdl:message>
	<wsdl:message name="GISGMPTransferMsgResponse">
		<wsdl:part name="outputmsg" element="unifo:GISGMPTransferMsg"/>
	</wsdl:message>
	<wsdl:portType name="SmevGISGMPService">
		<wsdl:operation name="GISGMPTransferMsg">
			<wsdl:input message="unifo:GISGMPTransferMsgRequest"/>
			<wsdl:output message="unifo:GISGMPTransferMsgResponse"/>
		</wsdl:operation>
	</wsdl:portType>
	<wsdl:binding name="SmevGISGMPServiceSOAP" type="unifo:SmevGISGMPService">
		<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
		<wsdl:operation name="GISGMPTransferMsg">
			<soap:operation soapAction="http://roskazna.ru/gisgmp/02000000/SmevGISGMPService/GISGMPTransferMsg"/>
			<wsdl:input>
				<soap:body use="literal"/>
			</wsdl:input>
			<wsdl:output>
				<soap:body use="literal"/>
			</wsdl:output>
		</wsdl:operation>
	</wsdl:binding>
	<wsdl:service name="SmevGISGMPService">
		<wsdl:port name="SmevGISGMPServiceSOAP" binding="unifo:SmevGISGMPServiceSOAP">
			<soap:address location="http://roskazna.ru/gisgmp/02000000/"/>
		</wsdl:port>
	</wsdl:service>
</wsdl:definitions>



Архив распаковываем так что бы папка xsd лежала рядом с wsdl.

Структура файлов должна выглядеть следующим образом (у меня это лежит в C:\dev\GisGmp\wimport\)
Код:

-|
 |- gen
 |- xsd
 |  |- entity
 |  |  |- directory
 |  |  |  |- куча файлов
 |  |  |- document
 |  |     |- куча файлов
 |  |- request
 |     |- куча файлов
 |- SmevGISGMPService.wsdl

И выполняем c:\Program Files\Java\jdk1.6.0_45\bin>wsimport -s C:\dev\GisGmp\wimport\gen -Xnocompile C:\dev\GisGmp\wimport\SmevGISGMPService.wsdl

Или берем NetBeans и создаем "Клиент веб-службы...", указываем wsdl. Название пакета оставляем пустым - иначе будет конфликт имен.

Отредактировано пользователем 2 июля 2015 г. 10:52:01(UTC)  | Причина: Не указана

RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
16 Страницы«<1112131415>»
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.