Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
|
Автор: afev  Может быть, у вас bouncycastle прописан в java.security? (выше JCP в списке провайдеров) Да, действительно, спасибо.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
|
Сформировал сейчас с помощью примера GisGmpServiceLowEnvelopeExample сообщение на импорт начисления (переделал с сообщения на импорт платежа), с моими данными - проверку на тестовом сервисе подпись прошла. Но тут все неймспейсы руками проставляются, остается вопрос как сделать корректное сообщение из классов, получаемых из wsdl.
п.с. до этого попробовал сформировать и подписать ссобщение примером GisGmpServiceCombinedExample, т.е. из java классов, подправив его для импорта начисления - ответ сервиса был, что подпись под сущностью некорректна.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
|
Есть люди, которым удалось корректно подписать сообщение, сформированное из классов, полученных из wsdl сервиса? Хоть одному это удалось сделать?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963  Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
|
Предположительно, eagames-ru и Inviz. |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
|
Автор: afev Предположительно, eagames-ru и Inviz. Было бы неплохо, если бы коллеги выложили хотя бы кусок кода как им удается скомпоновать классы так, что получается сообщение, которое можно валидно подписать. Может быть руками где-то неймспейсы правят, я не знаю даже. Если честно не понимаю, как расположение неймспейсов на хэш сущности повлиять может. Точнее он влияет конечно, но мы же неймспейсы не меняем после подписи сущности, они остаются какими и были. Посчитали хэш по сущности, записали его в DigestValue, потом элемент сущности вообще никак не меняется  . Отредактировано пользователем 26 июня 2015 г. 15:49:11(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 25.06.2015(UTC)
Сообщений: 8
Поблагодарили: 2 раз в 1 постах
|
Автор: ARnikev Автор: belgampaul Автор: ARnikev Цитата:
Абсолютно идентичная картина. Хэшируется локально одна xml (байты взятые из строки, представляющую собой xml фрагмент. Что происходит при проверке и какую xml ГИС ГМП хэширует пока не 100% ясно. Ясно,что хэшируется что-то другое.
Пока жду ответа от службы поддержки ЕТК, может кто-то выложить xml подписываемой сущности?
У моих сущностей есть префикс и namespace указан для этого префикса в корневом элементе сущности. А в soap-пакете namespace, используемый сущностями (FinalPayment, Charge), указан в тэге RequestMessage.
На форматах 1.15.0 xml был одинаков везде (в soap-пакете и в сущности). Там нигде не было неймспейсов.
Выше я выкладывал свой подписанный запрос на импорт начисления. upd. Кстати тоже думаю, что дело как-то касается неймспейсов. Выяснил, что старая подпись XMLDsig тоже перестала работать с сообщением нового формата. Так и не могу понять почему, элемент сущности после ее подписи и после подписи всего сообщения визуально выглядит одинаково. Но при проверке подписи сущности финального документа DigestValue получается совсем другим. Проблема в том, что я неймспейсы руками не проставляю даже, они маршалятся из java классов, которые я с wsdl сервиса получил. Да, видел примеры. В том-то и проблема, что у Вас как и у меня проблема похожая. В найденных примерах по этой ссылке http://bankir.ru/dom/thr...p;viewfull=1#post3251458 видно, что в пакете неймспейсы объявлены и на уровне сущности. Но в примере, где только сущность, неймспейсов больше. В ЕТК приняли заявку, но ответ неизвестно когда будет, а вопрос еще вчера вечером отправил. Все что пока есть это ими расчитанный хэш, но на основании каких данных рассчитан не упомянули. Да, мне тоже только хэш прислали и все)). Все выяснили наконец-то. Службе поддержки как обычно незачет. 2 дня ждать от них ответ, чтобы они еще раз прислали DigestValue, а не сущность, которую проверяли. Обошлись без службы поддержки. Подписываемая сущность у нас верная. Точнее Digest ее верен. Но подписываем мы не одновременно с отправлением. Сначала подписываем. Потом на другом статусе документ выгружаем. А JAXB, если его не научить, каждый раз может новые префиксы придумывать. В итоге получается картина, что Digest верный для нас, но данные изменились. В итоге: и сущность, которую подписываем и сущность, которую передаем в soap пакете должны быть идентичны.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
|
Автор: belgampaul
Все выяснили наконец-то. Службе поддержки как обычно незачет. 2 дня ждать от них ответ, чтобы они еще раз прислали DigestValue, а не сущность, которую проверяли.
Обошлись без службы поддержки. Подписываемая сущность у нас верная. Точнее Digest ее верен. Но подписываем мы не одновременно с отправлением. Сначала подписываем. Потом на другом статусе документ выгружаем. А JAXB, если его не научить, каждый раз может новые префиксы придумывать. В итоге получается картина, что Digest верный для нас, но данные изменились.
В итоге: и сущность, которую подписываем и сущность, которую передаем в soap пакете должны быть идентичны.
Что значит на другом статусе документ выгружаете? Вы убедились что ошибка в этом, удалось в итоге импортировать что-то корректно на тестовый сервис? Я только что проверил у себя, у меня все префиксы и сущность в целом остается неизменной, что до подписи, что после, что перед самой отправкой сообщения в ГИС ГМП...
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
|
Только что сформировал 2 запроса с абсолютно одинаковыми сущностями Charge, о чем говорит одинаковое значение DigestValue в теге подписи. Один запрос сформировал примером GisGmpServiceLowEnvelopeExample, который выложен на главной (https://www.cryptopro.ru/blog/2015/06/22/sozdanie-podpisi-xades-t-dlya-vzaimodeistviya-s-gis-gmp-po-spetsifikatsii-versii-116), второй сформировал примером GisGmpServiceCombinedExample. В итоге запрос сформированный руками ГИС ГМП схвал, а запрос сформированный из классов, полученных с wsdl сервиса - не схавал, ответ был "ЭП по сущностью не верна". Какой-то бред не правда ли? Написал вопрос в саппорт ГИС ГМП, придется опять кучу времени ждать ответа. пс. запросы можно тут посмотреть https://dropmefiles.com/rZswb
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 25.06.2015(UTC)
Сообщений: 8
Поблагодарили: 2 раз в 1 постах
|
Автор: ARnikev Автор: belgampaul
Все выяснили наконец-то. Службе поддержки как обычно незачет. 2 дня ждать от них ответ, чтобы они еще раз прислали DigestValue, а не сущность, которую проверяли.
Обошлись без службы поддержки. Подписываемая сущность у нас верная. Точнее Digest ее верен. Но подписываем мы не одновременно с отправлением. Сначала подписываем. Потом на другом статусе документ выгружаем. А JAXB, если его не научить, каждый раз может новые префиксы придумывать. В итоге получается картина, что Digest верный для нас, но данные изменились.
В итоге: и сущность, которую подписываем и сущность, которую передаем в soap пакете должны быть идентичны.
Что значит на другом статусе документ выгружаете? Вы убедились что ошибка в этом, удалось в итоге импортировать что-то корректно на тестовый сервис? Я только что проверил у себя, у меня все префиксы и сущность в целом остается неизменной, что до подписи, что после, что перед самой отправкой сообщения в ГИС ГМП... >>Что значит на другом статусе документ выгружаете? Это значит, что сущность подписывается на одном статусе, а пакет отправляется на другом. В пакете раньше пространства имен в сущности могли отличаться от тех, что были использованы при подписании, т.к. jaxb по-умолчанию сам выбирает префиксы. Выгрузить пока не удалось. Что удалось выяснить, так это-то, что код в архиве с первой страницы содержит ошибку. Во всяком случае DigestValue, для сущности неправильно генерит с корректного примера. Но для нас эта проблема неактуальна. Система использует нативный КриптоПро провайдер.
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 05.08.2014(UTC)
Сообщений: 12
Поблагодарили: 2 раз в 2 постах
|
Еще офтоп Автор: 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". Архив со схемами распакован в тот-же каталог с сохранением иерархии каталогов. Что делать, подскажите.
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
