Отправлять сообщения SOAP через WCF с MTOM и Content-Transfer-Encoding: 7-бит

Я пытаюсь отправить сообщение SOAP через WCF в IRS, но оно продолжает получать отказ, потому что мое вложение MTOM отформатировано неправильно.

Я сузил проблему до своего значения Content-Transfer-Encoding. Он установлен на Binary (сокращение от 8-bit).

Служба IRS хочет, чтобы я использовал 7-bit с вложением в 8-битной кодировке (другими словами, кодирую с помощью UTF-8, а затем гарантирую, что я не использую символы, отличные от ASCII).

Я уже использую специальный кодировщик сообщений для сжатия моих запросов (ответы возвращаются в виде обычного текста, тьфу). Вот как сейчас выглядит мой WriteMessage.

public override ArraySegment<byte> WriteMessage(Message message, int maxMessageSize, BufferManager bufferManager, int messageOffset) {
    // get an instance of the underlying encoder
    var encoder = new MtomMessageEncodingBindingElement() {
            MessageVersion = MessageVersion.Soap11WSAddressing10,
            WriteEncoding = System.Text.Encoding.UTF8
        }.CreateMessageEncoderFactory().Encoder;

    // write the message contents
    var uncompressed = encoder.WriteMessage(message, maxMessageSize, bufferManager, messageOffset);

    // compresses the resulting byte array
    return CompressBuffer(uncompressed, bufferManager, messageOffset);
}

Любые идеи? Когда я меняю свойство WriteEncoding на ASCII или UTF7, .NET выдает исключение ArgumentException и сообщает мне, что формат не поддерживается.


person Dave    schedule 27.01.2016    source источник
comment
Я думаю, что после некоторых дополнительных исследований 8-битное кодирование представляет собой меньшую проблему, чем тот факт, что MTOM пытается закодировать заголовок безопасности WSS (что приводит к оптимизации сертификата во вложении MTOM). Это делается WCF вне моего контроля, поэтому я собираюсь написать собственный кодировщик сообщений, чтобы преодолеть это. Надеюсь, кто-то здесь может дать мне лучший ответ, если он существует, прежде чем я зайду слишком далеко :)   -  person Dave    schedule 29.01.2016


Ответы (2)


Я использую Java Apache CXF и WSS4J для решения IRS, но если вы получаете эту ошибку: «Сообщение было неправильно отформатировано и / или не может быть интерпретировано. Ознакомьтесь со стандартами XML, изложенными в разделе 3 документа« Состав и справочные материалы для отправки AIR ». Руководство находится по адресу https://www.irs.gov/for-Tax-Pros/Software-Developers/Information-Returns/Affordable-Care-Act-Information-Return-AIR-Program, исправьте любые проблемы и попробуйте опять таки." это потому, что IRS ожидает этого:

Content-Type: application/xml
Content-Transfer-Encoding: 7bit
Content-ID: <6920edd2-a3c7-463b-b336-323a422041d4-1@blahurn:us:gov:treasury:irs:common>
Content-Disposition: attachment;name="1094B_Request_BBBBB_20151019T121002000Z.xml" 
person Tim Schumacher    schedule 28.01.2016
comment
После того, через что мы прошли через .NET и WCF, это, вероятно, намного более простой подход. Я слышал о людях, использующих Java, у которых возникают проблемы с подписью, но, скорее всего, они просто не понимают безопасности SOAP. - person Dave; 08.02.2016

Похоже, встроенный кодировщик MTOM в WCF не будет кодировать запрос, совместимый со службой IRS. Он кодирует все, что находит в запросе, закодированном в base64, включая BinarySecurityToken в подписанном запросе. Мне удалось получить запрос ближе к требованиям IRS, создав собственный кодировщик. В WriteMessage вы можете добавлять разделители MIME и перекодировать файл как вложение. Для правильной установки заголовков требуется инспектор исходящих сообщений: https://blogs.msdn.microsoft.com/carlosfigueira/2011/04/18/wcf-extensibility-message-inspectors/

person jabtri    schedule 04.02.2016
comment
Я считаю, что вы правы. Я применил немного другой подход и просто изменил части результата кодирования MTOM, которые мне не нужны. Я все еще работаю над тем, чтобы запрос был принят в настоящее время, но ошибка, которую я получаю, не может быть воспроизведена IRS, используя мой необработанный запрос на своей стороне. У меня назначен звонок на сегодня, чтобы выяснить, в чем проблема (надеюсь). Спасибо за участие! Если текущее решение, которое я использую, не работает, я попробую ваш метод. - person Dave; 05.02.2016
comment
Очень интересно узнать, работает ли это с C #. Я очень близко подошел к подходу к пользовательскому кодированию mtom, но теперь получаю сообщение об ошибке при синтаксическом анализе запроса: ‹errorcode› TPE1106 ‹/errorcode› ‹faultdetails› Обнаружено недопустимое содержимое, начиная с элемента «Подпись». На данном этапе не ожидается никакого дочернего элемента ‹/faultdetails› ... Поскольку единственный элемент подписи находится в токене безопасности, а безопасность уже подтверждена, я предполагаю, что IRS начинает анализировать заголовки конверта. Возможно, из-за того, что заголовки безопасности .NET не имеют пространства имен wsse, возникает эта ошибка. - person jabtri; 07.02.2016
comment
Я заставил MTOM работать (пришлось действительно взломать WCF, чтобы заставить его работать), и теперь мой заголовок безопасности недействителен из-за того, что я сделал с сообщением после кодирования MTOM. Я сообщу об этом через пару часов после (повторного) выполнения ручной подписи сообщения. - person Dave; 08.02.2016
comment
Похоже, что все сообщество .Net начинает сходиться на этих решениях примерно в одно и то же время. Очень интересно посмотреть эти обновления :) - person Bon; 08.02.2016