2015-08-13 2 views
0

Мы работаем с MobileFirst 6.3, mobilefirst server, работающим на RHEL linux. Мы подключаемся к SAP и использовали Discovery для создания кода адаптера и использовали эти сгенерированные вызовы адаптера, за исключением пользовательской аутентификации. Если мы создадим в SAP, это приведет к запросу HTTP POST, но адаптер всегда генерирует один HTTP-запрос HEAD перед этим фактическим запросом. У меня были клиенты SAP, которые жалуются на них (не то, что я лично думаю, что они причинили бы много вреда). Я также подтвердил это при проверке других вещей с помощью wirehark. Я могу себе представить, что они будут относиться к некоторым типам проверок подключения адаптерами, но не смогли найти никаких доказательств этого. Поиск подобных вопросов также вызывает проблемы, поскольку строки HTTP и HEAD настолько распространены в URL-адресах и html-коде.MobileFirst SAP Adapter http HEAD запросы

  • Может ли кто-нибудь подтвердить мою догадку о цели этих запросов HEAD?
  • Есть ли на них документация?
  • Являются ли они каким-либо образом настраиваемыми (и в этом случае будут недостатки для отказа)?

определения адаптера:

.. 
    <connectivity> 
      <connectionPolicy xsi:type="nwgateway:NWGatewayHTTPConnectionPolicyType"> 
        <protocol>HTTP</protocol> 
        <domain>our.complex.host</domain> 
        <port>10084</port> 
        <connectionTimeoutInMilliseconds>30000</connectionTimeoutInMilliseconds> 
        <socketTimeoutInMilliseconds>30000</socketTimeoutInMilliseconds> 
        <serviceRootUrl>/sap/opu/odata/sap/OUR_CUSTOM_REQS/</serviceRootUrl> 
        <!-- Following properties used by adapter's key manager for choosing specific certificate from key store 
        <sslCertificateAlias></sslCertificateAlias> 
        <sslCertificatePassword></sslCertificatePassword>--> 
        <maxConcurrentConnectionsPerNode>50</maxConcurrentConnectionsPerNode>   
      </connectionPolicy> 
    </connectivity> 

.. 
    <procedure name="createOurCustomObjectHeader" securityTest="OurCustomSecurityTest" connectAs="endUser"/> 
.. 

код адаптера:

function createOurCustomObjectHeader(content) { 
    var request = { 
      CollectionName: "OurCustomObjectHeaderSet", 
      Content : content 
    }; 
    return WL.Server.createNWBusinessObject(request); 
} 

Защитный код теста:

<customSecurityTest name="OurCustomSecurityTest"> 
     <test realm="wl_antiXSRFRealm" /> 
     <!-- test realm="wl_authenticityRealm"/ --> 
     <test realm="wl_remoteDisableRealm" /> 
     <test realm="OurCustomRealm" isInternalUserID="true" /> 
     <test realm="wl_deviceNoProvisioningRealm" isInternalDeviceID ="true" /> 
    </customSecurityTest> 
+0

Непонятный. Можете ли вы предоставить код реализации адаптера? –

+0

Добавлены надежные части кода. – jarkko

ответ

1

Посмотрев на код, по-видимому, мы используем запрос HEAD, чтобы получить CSRF-токен из шлюза, а затем вставить этот токен в заголовок фактического запроса на создание. Если вы ссылаетесь на SAP's documentation, для всех операций модификации требуется заголовок маркера CSRF для целей безопасности.

В 6.3 или даже более поздних версиях MobileFirst, я боюсь, что никакой конфигурации вокруг этой конфигурации не существует из-за положений инфраструктуры шлюза SAP.