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

Уведомление

Icon
Error

8 Страницы«<5678>
Опции
К последнему сообщению К первому непрочитанному
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,360
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 16 раз
Поблагодарили: 550 раз в 525 постах
Если не сложно, выложите, могут пригодиться.
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) загружен 32 раз(а). 2015_06_30_22_01_23_535_response.txt (13kb) загружен 18 раз(а). 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)  | Причина: Не указана

Offline Inviz  
#131 Оставлено : 2 июля 2015 г. 10:49:54(UTC)
Inviz

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

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

Поблагодарили: 1 раз в 1 постах
Автор: afev Перейти к цитате
Предположительно, eagames-ru и Inviz.


У меня пока не получилось. Т.к. проверку метки времени еще не сделали - пользуемся старой подписью (она нормально принимается пока что).
Сейчас разгребаем кучу проблем нового формата...
Скоро надеюсь попробовать Ваш вариант.
Offline belgampaul  
#132 Оставлено : 2 июля 2015 г. 13:45:40(UTC)
belgampaul

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

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

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



Ясно, у вас все сложно как-то). У нас вроде нет такого рода проблем. Спасибо за пояснения.

Добавил библиотеку в пост выше.



Offline ARnikev  
#133 Оставлено : 2 июля 2015 г. 14:37:39(UTC)
ARnikev

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
afev, посмотрите ЛС пожалуйста.
Offline Bpar  
#134 Оставлено : 8 июля 2015 г. 10:31:30(UTC)
Bpar

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

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

Поблагодарили: 2 раз в 2 постах
Offline ctacon183  
#135 Оставлено : 12 ноября 2015 г. 8:59:34(UTC)
ctacon183

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

Группы: Участники
Зарегистрирован: 12.11.2015(UTC)
Сообщений: 2
Российская Федерация
Откуда: г Барнаул

Добрый день. Используя ваш пример подпись успешно сформировалась. Но при отправке soap запроса через jaxws получаю исключение:
Цитата:

javax.xml.ws.WebServiceException: com.ctc.wstx.exc.WstxIOException: Invalid white space character (0x4) in text to output
at com.sun.xml.ws.encoding.StreamSOAPCodec.encode(StreamSOAPCodec.java:112)
at com.sun.xml.ws.encoding.SOAPBindingCodec.encode(SOAPBindingCodec.java:278)
at com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:165)
at com.sun.xml.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:95)
at com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:133)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
at com.sun.xml.ws.client.Stub.process(Stub.java:319)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:157)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:109)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at $Proxy41.gisgmpTransferMsg(Unknown Source)
at ....sendPaymentRequest(GisClientV16.java:106)
Caused by: com.ctc.wstx.exc.WstxIOException: Invalid white space character (0x4) in text to output
at com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:511)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:135)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.util.DOMUtil.serializeNode(DOMUtil.java:138)
at com.sun.xml.ws.message.saaj.SAAJMessage.writeTo(SAAJMessage.java:365)
at com.sun.xml.ws.encoding.StreamSOAPCodec.encode(StreamSOAPCodec.java:109)
... 17 more
Caused by: java.io.IOException: Invalid white space character (0x4) in text to output
at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
at com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters(BufferingXmlWriter.java:531)
at com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:509)
... 37 more





Скорее всего проблема в том, что в итоговом xml xades4j формирует X509IssuerName так:
Цитата:

<ns3:X509IssuerName>CN=&#4;&#30;&#4;&#30;&#4;&#30;\00 \00\"&#4;&#26;&#4; &#4;&#24;&#4;&#31;&#4;\"&#4;&#30;\00-&#4;&#31;&#4; &#4;&#30;\00\",O=&#4;&#30;&#4;&#30;&#4;&#30;\00 \00\"&#4;&#26;&#4; &#4;&#24;&#4;&#31;&#4;\"&#4;&#30;\00-&#4;&#31;&#4; &#4;&#30;\00\",L=&#4;&#28;&#4;\&gt;&#4;A&#4;:&#4;2&#4;0,ST=&#4;3\00.\00 &#4;&#28;&#4;\&gt;&#4;A&#4;:&#4;2&#4;0,C=RU,1.2.840.113549.1.9.1=#16107163614063727970746f70726f2e7275,STREET=&#4;C&#4;\;\00.\00 &#4;!&#4;C&#4;I&#4;Q&#4;2&#4;A&#4;:&#4;8&#4;9\00 &#4;2&#4;0&#4;\;\00 &#4;4\00.\00 \001\008,1.2.643.3.131.1.1=#120c303037373137313037393931,1.2.643.100.1=#120d31303337373030303835343434</ns3:X509IssuerName>

Думаю из-за наличия кирилицы, что с точки зрения xml считается не корректным. Как на это можно повлиять?




********************************************************************************************


Решил проблему следующим образом: удалил элемент X509IssuerName из подписанного сообщения. Смев вернул успешный ответ, видимо этот элемент не нужен.
Код, может кому пригодится:
Цитата:

signer.sign(dataObjects, nodeToSign);
org.w3c.dom.Node issuerSerial = XPathAPI.selectSingleNode(nodeToSign.getParentNode(), "//*[local-name()='IssuerSerial']");
org.w3c.dom.Node issuerName = XPathAPI.selectSingleNode(issuerSerial, "//*[local-name()='X509IssuerName']");
issuerSerial.removeChild(issuerName);


Интересно, есть ли более элегантное решение?

Отредактировано пользователем 12 ноября 2015 г. 11:36:20(UTC)  | Причина: Не указана

Offline solncer1  
#136 Оставлено : 27 ноября 2015 г. 15:16:18(UTC)
solncer1

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

Группы: Участники
Зарегистрирован: 05.11.2015(UTC)
Сообщений: 2
Женщина
Российская Федерация

Добрый день! У меня аналогичная проблема с кодировкой ds:X509IssuerName. Но удаление этого элемента недопустимо, потому что он входит в SignedProperties, и соответственно подпись после его удаления не валидируется. Подскажите пожалуйста, как выставить правильную кодировку.
Offline Franco  
#137 Оставлено : 30 ноября 2015 г. 12:07:57(UTC)
Franco

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

Группы: Участники
Зарегистрирован: 30.11.2015(UTC)
Сообщений: 4
Российская Федерация

Коллеги, Добрый день.

Перечитал тему, но ни один вариант (а я насчитал 2 более менее рабочих варианта) у меня не заработал.
Кто-нибудь нашел рабочее решение для подписи сообщения в формате XAdES?
Offline Franco  
#138 Оставлено : 30 ноября 2015 г. 13:55:41(UTC)
Franco

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

Группы: Участники
Зарегистрирован: 30.11.2015(UTC)
Сообщений: 4
Российская Федерация

Про генерация классов по wsdl: я генерировал классы не с помощью компилятора wsimport, а с помощью xjc (соответственно, использовалась wsdl, а, значит, корневая xsd). Все классы сгенерились, руками ничего не правил.
Offline Franco  
#139 Оставлено : 30 ноября 2015 г. 14:06:24(UTC)
Franco

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

Группы: Участники
Зарегистрирован: 30.11.2015(UTC)
Сообщений: 4
Российская Федерация

Было бы прекрасно, если бы кто-нибудь поделился кодом...
Offline ctacon183  
#140 Оставлено : 30 ноября 2015 г. 14:15:24(UTC)
ctacon183

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

Группы: Участники
Зарегистрирован: 12.11.2015(UTC)
Сообщений: 2
Российская Федерация
Откуда: г Барнаул

Автор: solncer1 Перейти к цитате
Добрый день! У меня аналогичная проблема с кодировкой ds:X509IssuerName. Но удаление этого элемента недопустимо, потому что он входит в SignedProperties, и соответственно подпись после его удаления не валидируется. Подскажите пожалуйста, как выставить правильную кодировку.


Верно. Я сначала подумал, что проверка подписи прошла, когда получил успешный ответ на платеж. Но когда запросил статус, вернулась ошибка проверки подписи.

Вообще проблема в том, что javax.security.auth.x500.X500Principal.getName() по умолчанию использует X500Principal.RFC2253 формат, который печатает не корректные для xml символы. Для меня корректно печатает формат RFC1779, проверить можно так:
Цитата:

((X509Certificate)publicCert).getIssuerX500Principal().getName(X500Principal.RFC1779);

xades4j как раз вызывает метод без аргументов. Выкачал исходники xades4j и поменял в классах, где встречается getIssuerX500Principal().getName() на getIssuerX500Principal().getName(X500Principal.RFC1779). После чего стал использоваться нормальный текст.
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
8 Страницы«<5678>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.