В ходе проверок было получено несколько разных ответов:
5 - Импортируемые данные уже присутствуют в системе;
8 - Нет прав на импорт/ уточнение/аннулирование сущности данного типа;
13 - ЭП под сущностью (запросом) не верна.
Прилагаем архив, в котором находятся:
1. Несколько xml документов в папке data. Каждая пара называется SOAP_etalon_pay.xml_[xxx] и SOAP_etalon_pay_response_1_id.xml_[xxx].
Хвост в виде _xxx перед запуском следует убирать (то есть выбирается та или иная пара документов).
Документ SOAP_etalon_pay - первый отравляемый запрос (импорт платежа), документ SOAP_etalon_pay_response_1_id - запрос с package id для проверки обработки.
Файлов-примеров несколько (пар), т.к. в них прописаны разные отправители (некие 000147 и 0000a1).
Пара документов с расширением _0000a1 (sender=0000a1) дает при выполнении код 8, пара документов с расширением _000147 (sender=000147) дает код 13.
Документ SOAP_etalon_pay.xml_000147_exists (sender=000147) в паре с SOAP_etalon_pay_response_1_id.xml_000147 дает код 5.
Зависимость между кодом ошибки и этапом проверки не ясна, однако:
а) в случае получения кода 8 (документы SOAP_etalon_pay.xml_0000a1 и SOAP_etalon_pay_response_1_id.xml_0000a1) изменение подписи или штампа ни на что не влияет, видимо, до проверки подписи не доходит;
б) в случае c кодом 5 (данные уже присутствуют в системе) - SOAP_etalon_pay.xml_000147_exists почти идентичен SOAP_etalon_pay.xml_000147 (для получателя 000147; что нужно изменить, чтобы этот документ стал уникальным - неясно), хотя SOAP_etalon_pay.xml_000147 дает в итоге 13.
В инструкции ГИС ГМП упоминается "Загрузка и обновление сертификатов ключей проверки ЭП участников" - возможно, у sender 000147 имеется какой-то другой сертификат в системе(?).
2. Архив примеров (samples-sources.jar).
В частности, добавлен пример создания XAdES-T - XAdESExample в пакет xades и GisGmpServiceExample в xades.gisgmp.
С помощью XAdESExample можно подписать и проверить документ (узел). Перед запуском нужно иметь в папке data (см. архив) пару файлов с именами SOAP_etalon_pay.xml и SOAP_etalon_pay_response_1_id.xml и скопировать ключевой контейнер test. Для XAdES-T используется тестовый ключевой контейнер из класса Container2001 (в пакете CAdES.configuration.container) и хранилище доверенных сертификатов xadesTrustStore с паролем 1 для проверки подписи.
Пример GisGmpServiceExample в пакете xades.gisgmp осуществляет последовательно подпись документа с именем SOAP_etalon_pay.xml, затем создание Security Header и подпись всего документа с помощью специального контейнера с сертификатом, выпущенным в аккредитованном УЦ (иначе не проходила проверка подписи). Затем из полученного ответа извлекается package id, формируется запрос из документа SOAP_etalon_pay_response_1_id.xml с подстановкой package id, запрос с package id отправляется и получается ответ.
Существование проблемы с версией xades в документе пока не установлено.
3. Тестовый ключевой контейнер test с паролем 1, выпущен в тестовом УЦ (для подписи XAdES-T).
4. Хранилище доверенных сертификатов xadesTrustStore с паролем 1 в папке data (для проверки подписи XAdES-T).
Потребуются зависимости (xades - для XAdeS-T подписи и wss4j для общей подписи) из папки dependencies:
aopalliance-1.0.jar
bcpkix-jdk15on-1.50.jar
bcprov-jdk15on-1.50.jar
guice-2.0.jar
guice-multibindings-2.0.jar
axis-1.4.jar
axis-jaxrpc-1.4.jar
commons-discovery-0.5.jar
commons-logging-1.1.1.jar
hamcrest-core-1.3.jar
joda-time-1.6.2.jar
opensaml-2.5.1-1.jar
openws-1.4.2-1.jar
serializer-2.7.1.jar
slf4j-api-1.7.9.jar
wsdl4j-1.6.2.jar
wss4j-1.6.18.jar
xades4j-1.3.2.jar
xalan-2.7.0.jar
xercesImpl-2.9.1.jar
xml-apis-1.3.04.jar
xmlsec-1.5.0.jar
xmltooling-1.3.2-1.jar
, установленный JCP со снятыми ограничениями и ключевой контейнер с сертификатом, выпущенным в аккредитованном УЦ (для общей подписи в Security Header).
Пожалуй, лучше всего было, если бы кто-нибудь попробовал проверить, используя правильный (существующий) sender (recipient) в документе (и другие правильно заполненные поля).
P.S.
АрхивОтредактировано пользователем 10 лет назад
| Причина: Не указана