Teiid 11.2.0 / Wildfly 11.2 with SAPUI5 / OPENUI5 communication problem

[cjohn001]

Hello together,

I am trying to use SAPUI5 in a Single Page App to display data from a TEIID VDB. When SAPUI5 ODATA V4 data model is bound to the odata service I run into several errors. One note on that, I connect via proxy (grunt-connect-proxy2) to the odata service. Basic Auth works. The metadata file above the marked service folder in the attached image is the actual metadata file of the service which, as you can see, gets loaded correctly. So no CORS issue or authorization issue.

1. First one seems to be related to an CSRF Token request as far as I understand. Seems that Wildfly is not answering the CSRF Token fetch request. Is there a way to configure Wildfly to answer the request and how would this config option look like?

The following is a screenshot from the browser log:

In standalone-teiid.xml I already tried the following CORS Headers:

<subsystem xmlns="urn:jboss:domain:undertow:4.0">

            <buffer-cache name="default"/>

            <server name="default-server">

                <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>

                <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>

                <host name="default-host" alias="localhost">

                    <location name="/" handler="welcome-content"/>

                    <filter-ref name="server-header"/>

                    <filter-ref name="x-powered-by-header"/>

                    <filter-ref name="Access-Control-Allow-Origin"/>

                    <http-invoker security-realm="ApplicationRealm"/>

                </host>

            </server>

            <servlet-container name="default">

                 <jsp-config />

                <websockets/>

            </servlet-container>

            <handlers>

                <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>

            </handlers>

            <filters>

                <response-header name="server-header" header-name="Server" header-value="WildFly/11"/>

                <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>

                <response-header name="Access-Control-Allow-Origin" header-name="Access-Control-Allow-Origin" header-value="*"/>

            </filters>

        </subsystem>

I also tried the following config with and without adding HEAD in the Access-Control-Allow-Methods. But all configs have the same effect. It does not work.

      <subsystem xmlns="urn:jboss:domain:undertow:4.0">

            <buffer-cache name="default"/>

            <server name="default-server">

                <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>

                <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>

                <host name="default-host" alias="localhost">

                    <location name="/" handler="welcome-content"/>

                    <filter-ref name="server-header"/>

                    <filter-ref name="x-powered-by-header"/>

                    <filter-ref name="gzipFilter" predicate="exists('%{o,Content-Type}') and regex(pattern='(?:application/javascript|text/css|text/html|text/xml|application/json)(;.*)?', value=%{o,Content-Type}, full-match=true)"/>

                    <filter-ref name="Access-Control-Allow-Origin"/>

                    <filter-ref name="Access-Control-Allow-Methods"/>

                    <filter-ref name="Access-Control-Allow-Headers"/>

                    <filter-ref name="Access-Control-Allow-Credentials"/>

                    <filter-ref name="Access-Control-Max-Age"/>

                    <http-invoker security-realm="ApplicationRealm"/>

                </host>

            </server>

            <servlet-container name="default">

                <jsp-config/>

                <websockets/>

            </servlet-container>

            <handlers>

                <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>

            </handlers>

            <filters>

                <response-header name="server-header" header-name="Server" header-value="WildFly/11"/>

                <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>

                <response-header name="Access-Control-Allow-Origin" header-name="Access-Control-Allow-Origin" header-value="*"/>

                <response-header name="Access-Control-Allow-Methods" header-name="Access-Control-Allow-Methods" header-value="GET, POST, OPTIONS, PUT"/>

                <response-header name="Access-Control-Allow-Headers" header-name="Access-Control-Allow-Headers" header-value="accept, authorization, content-type, x-requested-with"/>

                <response-header name="Access-Control-Allow-Credentials" header-name="Access-Control-Allow-Credentials" header-value="true"/>

                <response-header name="Access-Control-Max-Age" header-name="Access-Control-Max-Age" header-value="1"/>

            </filters>

        </subsystem>

Can someone give me a hint how I have to configure TEIID to get it working together with SAPUI5.

I observed a further issue, from which I do not know if it is related to a follow up or the same issue on the just mentioned described one (there is also a X-CSRF-Token: Fetch involved), or if a have something more missing in the configuration. The issue happens when I use an aggregation binding to bind a odata collection to a sapui5 list.

Attached is the full error message:

1. Request URL: http://localhost:9001/odata4/svc/my_nutri_diary/$batch
2. Request Method: POST
3. Status Code: 406 Not Acceptable
4. Remote Address: [::1]:9001
5. Referrer Policy: no-referrer-when-downgrade
1. Response Headersview source
   1. access-control-allow-credentials: true
   2. access-control-allow-origin: http://localhost:9001
   3. cache-control: no-cache, no-store, must-revalidate
   4. connection: close
   5. content-encoding: gzip
   6. content-length: 125
   7. content-type: application/json;odata.metadata=minimal
   8. date: Mon, 12 Nov 2018 20:04:30 GMT
   9. expires: 0
   10. odata-version: 4.0
   11. pragma: no-cache
   12. server: WildFly/11
   13. x-powered-by: Undertow/1
2. Request Headersview source
   1. Accept: multipart/mixed
   2. Accept-Encoding: gzip, deflate, br
   3. Accept-Language: de
   4. Authorization: Basic SU1TVXNlcjpJTVM0Zm9ydW0l
   5. Connection: keep-alive
   6. Content-Length: 329
   7. Content-Type: multipart/mixed; boundary=batch_id-1542053070786-11
   8. Cookie: sidebar_collapsed=false; cycle_analytics_help_dismissed=1; __utmz=111872281.1539128843.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=111872281.767670437.1539128843.1541866362.1541870562.42
   9. DNT: 1
   10. Host: localhost:9001
   11. MIME-Version: 1.0
   12. OData-MaxVersion: 4.0
   13. OData-Version: 4.0
   14. Origin: http://localhost:9001
   15. Referer: http://localhost:9001/
   16. User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1
   17. X-CSRF-Token: Fetch
   18. X-Requested-With: XMLHttpRequest
3. Request Payload
   1. --batch_id-1542053070786-11 Content-Type:application/http Content-Transfer-Encoding:binary GET Profile?$skip=0&$top=100 HTTP/1.1 Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true Accept-Language:de Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true --batch_id-1542053070786-11--

[shawkins]

I'm researching the CSRF issue, but don't have anything on that yet.

From what you have shown on the batch issue, you should be seeing an exception in the teiid log similar to:

WARN: TEIID16053 Unable to process odata request due to: The content-type range 'multipart/mixed' is not supported as value of the Accept header. Increase the log level to see the entire stack trace.

The full olingo exception message is:

The combination of type and subtype multipart/mixed != [application/json;odata.metadata=minimal, application/json;odata.metadata=none, application/json, application/json;odata.metadata=full, application/atom+xml, application/xml]

In other words olingo only expects to see multipart/mixed as the content type for a batch request, and Accept must be one of the standard formats.

[shawkins]

On the CSRF issue, we had to add handing in our OData service specifically for CORS - [TEIID-4366] Provide CORS support on OData Service - JBoss Issue Tracker

That logic handles CORS requests using the OPTIONS method - there is no handling for CSRF HEAD requests.  So there are no changes needed to the undertow configuration for CORS when using Teiid OData services - also undertow has no built-in handling [UNDERTOW-1376] Add support of CORS in Undertow - JBoss Issue Tracker

There is a reference to allowing the X-CSRF-TOKEN with OData 4 [ODATA-262] Specify how OData services can be protected against cross-site request forgery (CSRF or XSRF) - OASIS Techni…  that references the GET method.  I don't see a further reference in the specification nor in the Olingo library.

So either we would need to add handling in our OData service similar to the CORS handling, or there is a pac4j project that claims to add support for CSRF for undertow.

[cjohn001]

Hello Steven,

first of all, thanks a lot for your feedback! I am not sure if I could correctly follow you on this. So as a matter of principle you are saying CSRF should work out of the box, but not on a HEAD request but rather a GET request, and further, it is no configuration of UNDERTOW required for this? I will try this out via sending a request manually. I came over the description here

Gateway protection against Cross-Site Request Forgery attacks | SAP Blogs

which as a matter of principle also speaks about GET and not HEAD requests. I will post the question into an SAP forum to see if this is a bug in SAPUI5.

Regarding the batch request my log is empty. As I am quite new to Wildfly, could you please tell me how to increase the log level and for which modules? However, I assume the topic is also related to the CSRF token, as it includes a fetch rather than a real toke value.

Do you know if there is an option to deactivate the entire CSRF-TOKEN flow in SAPUI5? As I assume this is redundant anyway, if I use the odata service together with Keycloak bearer tokens?

[shawkins]

> So as a matter of principle you are saying CSRF should work out of the box, but not on a HEAD request but rather a GET request

That's from that old odata issue - but there is no mention of CSRF in any of the OData 4.0 specification nor is it handled by the Olingo framework. 

So it is not presently expected to work.

> and further, it is no configuration of UNDERTOW required for this?

There is a reference to CSRF support with the pac4j undertow security library, but that is not something that I have experience with.

> Regarding the batch request my log is empty.

Which log are you looking at?  There should be an entry in standalone/log/server.log

> could you please tell me how to increase the log level and for which modules?

Actually you shouldn't need to increase the log level to see the top level TEIID16053 warning from Teiid.

There's some docs on logging at Logging · GitBook

> However, I assume the topic is also related to the CSRF token, as it includes a fetch rather than a real toke value.

It may not be related.  If you issue any request using Accept multipart/mixed, Olingo will always return a 406 error.

> Do you know if there is an option to deactivate the entire CSRF-TOKEN flow in SAPUI5?

I am not familiar enough.  tejones any ideas?

> As I assume this is redundant anyway, if I use the odata service together with Keycloak bearer tokens?

Are you assuming in that case that SAPUI will no longer use the CSRF-TOKEN?

[cjohn001]

>That's from that old odata issue - but there is no mention of CSRF in any of the OData 4.0 specification nor is it handled by the Olingo framework

>So it is not presently expected to work.

Well, this unfortunately means that I will not be able to use SAPUI5 together with TEIID if I will find no way to disable this CSRF token handling

>> Which log are you looking at?  There should be an entry in standalone/log/server.log

I looked into the wildfly webinterface under Runtime/Logfiles. Actually I would have expected to the the same logfile there. Not sure why this is not the case. In the file you mentioned I have got the following

2018-11-13 18:00:32,659 WARN  [org.teiid.PROCESSOR] (default task-2)  TEIID16053 Unable to process odat

a request due to: HTTP method 'HEAD' not allowed for this resource. Increase the log level to see the e

ntire stack trace.

[cjohn001]

>Are you assuming in that case that SAPUI will no longer use the CSRF-TOKEN?

Well, my assumption is, that the CSRF token is only needed as a kind of session token, to detect requests that my browser makes on behalf of me based on malicious scripts from a different website. Hence, if I have a second tab to a different website open and execute there a script which makes a request to a service I am logged in. This script than does not know the CSRF token. However, if I send a keycloak bearer token with each  server request which is checked bz the server, I would assume that this will be equivalent to using a CSRF token.

Unfortunately, this is totally independent of SAPUI5. Hence I need to find a config option to disable this feature. SAPUI5 has a odata.v2 and odata.v4 data model. In the odata.v2 model the behaviour CSRF enable/disable can be configured. Unfortunately not in the constructor of the odata.v4 model Hope there is a different option which I have not found yet.

[tejones]

Hi Christoph,

Maybe give this[1] a try? - "The client needs to pass an HTTP Header 'X-Requested-With' with a value of 'X' during the HTTP call."

[1] Disable Authentication pop up and CSRF token for OData calls (using SAP Netweaver Gateway) | SAP Blogs

Thanks,

Ted

[cjohn001]

Hello Ted,

thanks, I just came over this blog as well but still try to find a way on how to add this header to the request. Seems that the odata.v4 model does not support it or has a different interface. odata.v2 had .addHeaders() function for this.  Do you have a hint on how to set up this header?

[cjohn001]

Hello Ted,

I have just added the header via

$.ajaxSetup({headers: {'X-Requested-With': 'X'}});

However, I still see the X-CSRF-TOKEN = fetch request in the header and the HEAD query is also still present

[tejones]

Hi Christoph,

Are you using SAP Gateway? It's possible to disable CSRF on the server. See https://help.sap.com/saphelp_gateway20sp12/helpdata/en/e6/cae27d5e8d4996add4067280c8714e/frameset.htm . See the section at the bottom (Changing the Default CSRF Protection Mechanism).

[cjohn001]

Hello Ted,

no, I am trying the open source path. My backend is a Wildfly Server 11.0 which uses TEIID 11.2.0 to serve a mysql database.

[cjohn001]

Hello Ted,

it looks like I made some progress. By reconfiguring the sapui5 odata model I do not get the http errors anymore. However, now SAPUI5 is crashing by parsing annotations. Is there a way to configure teiid to deliver json format as the default instead of xml-based atom? And if so, how is this option to be configured? Thanks for your help.

[tejones]

Hi Christoph,

That's great. Did you add the headers to the data model?

To get JSON back in Teiid, add $format=json to the end of your odata url.

[cjohn001]

Hello Ted,

I know the option with the $format=json. However, this does not help me here. The OpenUI5 library consumes the odata model and I cannot add parameters there to request json format for consumption. Therefore, my hope was that I could configure teiid somehow in standalone-teiid.xml to provide json by default.

1. So is there an option?

What I changed was the app configuration in the OpenUI5 manifest.json my model is now setup with

    "sap.app": {

        "dataSources": {

            "default": {

                "uri": "http://localhost:9001/odata4/svc/my_nutri_diary/",

                "type": "OData",

                "settings": {

                    "odataVersion": "4.0"

                }

            },

     }

and:

"sap.ui5": {

            "": {

                "dataSource": "default",

                "settings": {

                    "autoExpandSelect": true,

                    "operationMode": "Server",

                    "groupId": "$direct",

                    "synchronizationMode": "None"

                }

            }

}

However, I  get the following errors now. I suspect the errors could come from processing of the annotations in metadata.xml. But I am not sure about this yet.

sap-ui-core.js:179 2018-11-15 00:03:17.985199 Failed to update cache for binding sap.ui.model.odata.v4.ODataListBinding: /Account - TypeError: Cannot read property 'indexOf' of null

    at V.a.resolveAlias (http://localhost:9001/resources/sap/ui/core/library-preload.js:3689:46)

    at V.a.processAnnotation (http://localhost:9001/resources/sap/ui/core/library-preload.js:3682:89)

    at V.processElement (http://localhost:9001/resources/sap/ui/core/library-preload.js:3851:50)

    at V.a.traverse (http://localhost:9001/resources/sap/ui/core/library-preload.js:3695:203)

    at V.a.traverse (http://localhost:9001/resources/sap/ui/core/library-preload.js:3695:459)

    at V.a.traverse (http://localhost:9001/resources/sap/ui/core/library-preload.js:3695:459)

    at V.a.traverse (http://localhost:9001/resources/sap/ui/core/library-preload.js:3695:459)

    at V.a.traverse (http://localhost:9001/resources/sap/ui/core/library-preload.js:3695:459)

    at V.a.traverse (http://localhost:9001/resources/sap/ui/core/library-preload.js:3695:459)

    at V.a.convertXMLMetadata (http://localhost:9001/resources/sap/ui/core/library-preload.js:3662:364) sap.ui.model.odata.v4.ODataParentBinding

Is there a way in Teiid designer to generate the vdb without annotations. This might help me to track down the issue.