Still problems with Access-Control-Allow-Origin

[Former Member]

Hello there,

i am developing in IntelliJ IDEA with an OpenUI5 SDK 1.36.5. While trying to access my Odata Service with an ODataModel i get continuously an access error seeing below:

What have i done?

Too make it short:

• Created a new project in SAP Gateway Service Builder (TAC: SEGW)
• Referenced a table with fields and data (not necessary, its working )
• Implemented the "GetEntitySet (Query)" Method in the folder "Service Implementation/VBAKUK_UI5Set" (= Name of the Entity Set)

 

To check the headers i use Postman. With http://[server]:[port]/sap/opu/odata/sap/ZUI5_IW74874_TEST_SRV/VBAKUK_UI5Set/ and an Basic Authorization Header (credentials to get access) i get all the data i want plus the "access-control-allow-origin →*" header.

Now to the code i have written

<script>
   sap.ui.localResources("sap_ui5_playground");
   sap.ui.localResources("util");
   sap.ui.localResources("i18n");
   var oView = sap.ui.view({

   viewName: "sap_ui5_playground.Main",
   type: sap.ui.core.mvc.ViewType.HTML
   });
   oView.placeAt("content");
</script>
<script>
   var url = "http://[host]:[port]/sap/opu/odata/sap/ZUI5_IW74874_TEST_SRV/";     //url as full address
   var oModel = new sap.ui.model.odata.ODataModel(url, false, "[username]", "[password]");     //name and pw as plain text here
   sap.ui.getCore().setModel(oModel, "odata");

   var oTable = new sap.ui.table.Table({

        width: "100%",
        title: "Daten aus dem SAP mit OData",
        editable: true,
        items: "{odata>/VBAKUK_UI5Set?$format=json&sap-client=201}"
   });
   oTable.addColumn(new sap.ui.table.Column({

        id: "Mandt",
        label: new sap.ui.commons.Label({

             text: "Mandt"
        }),
        template: new sap.ui.commons.TextView({

             text: "{odata>Mandt}"
        })

  }));

  [more columns]

  oTable.setModel(oModel);

  oTable.placeAt("content");

I tried several ways in coding to fix the issue yet, nothing worked. If you know any way further to help me i would really appreciate it. I am open for every hint you're might be able to give, so don't hesitate to answer

Best regards,

Max

[Former Member]

Hi Max,

according to your error messages, the cross-origin request that is denied by the browser is the one to access the metadata.

<your_service>/$metadata

You set the Access-Control-Cross-Origin header for the get_entityset in DPC_EXT but not for the metadata document. This will probably have to be done in the MPC_EXT class.

Best regards,

Frank

[Former Member]

Unfortunately, the header for service requests is set in the GW framework. I couldn't find any relevant BAdI's there either but I didn't look for too long.

That is strange, it seems that odd to allow changes to headers in the response of entities but not for metadata.

[Former Member]

Hey Frank,

i appreciate your hint about metadata. Sadly, i didn't find any suspicious too. As long as it works for now i will use Chrome with disabled security flag, trying out some special stuff if i have time for it and go further on developing currently.

Thanks for your help

[daniel_ruiz2]

hi Frank,

Odd? - It's an issue, as soon you lose total control of the code you end up with problems.. well, you always eventually do...

I'd assume the best way would be to extend the OData Handler (SICF Node) and manipulate your headers there - this way you can be sure you control what happens and it's still very clean and easy to roll back & switch if needed.

Cheers,

Dan.

[Former Member]

Yes, that's what I ended up doing.

[Former Member]

Hi Max,

I actually found a way. You can use a handler in the sicf node for gateway. See here for details:

The test method I implemented looks like this:

METHOD if_http_extension~handle_request.

     server->response->set_header_field(

       EXPORTING

         name  = 'Access-Control-Allow-Origin'

         value = '*'

     ).

     if_http_extension~flow_rc = if_http_extension~co_flow_ok_others_mand.

ENDMETHOD.

[Former Member]

Hello Frank,

I tried the same but the preflight request never reached the handlers. We have SSO SAML setup in the gateway during http debugging I've seen that the HTTP call always went first through the sequence of logon methods as defined in the SICF service before it entered the list of http handlers. Hence the anonymous HTTP OPTIONS call from the browser was already blocked by the SSO logon procedure.

How did you do that in your case? How did you allow an anonymous access while at the same time keeping a logon procedure for every other user?

Thank you for your feedback

[Former Member]

Hi Mark,

I'm not sure what the HTTP OPTIONS call would do. Never noticed it during my tests. And the oData V2 spec only mentions GET, POST, PUT/MERGE and DELETE HTTP.

(see here: Operations (OData Version 2.0) &amp;middot; OData - the Best Way to REST )

[Former Member]

Hello Frank,

with a CORS enabled browser a post to a SAP Gateway OData service would look like the following for a serviceXYZ:

1. HTTP OPTIONS anonymous   https://sapgateway.com/sap/opu/odata/sap/serviceXYZ/Data

2. HTTP POST       myuser         https://sapgateway.com/sap/opu/odata/sap/serviceXYZ/Data

Which browser do you use for the data posting? Which login method have you configured in the SICF service?

There is a thread which mentions that according to the CORS spec a CORS enabled application server must be able to handle the anonymous call (1). I don't see how the SAP Gateway SICF framework is able to do that. From what I've seen the SICF processes requests as such:

1. ICM receives HTTP request

2. SICF service executes Login chain

3. Once passed HTTP handler chain is being executed

The POST to the OData service failed in my case with the OPTIONS call (1) issued by Chrome because of the missing user and didnt even reach the HTTP handler chain. The same call worked from IE9 due to the missing CORS.

Mark

[Former Member]

Good to know. I guess it won't work then.