[FIX] sap.ui.model.odata: add request header "X-Requested-With" #3324
Conversation
In case the session has timed out and a new GET request comes in, the @sap/approuter component responds with status 200 and HTML content to store session and redirect the browser. By indicating the request originates from an AJAX call, the @sap/approuter is informed that it should return a 401 in case the session has timed out.
|
|
|
Hello @piejanssens , |
|
Hi @piejanssens , thanks for this contribution. The code looks good, but the tests need to be adjusted such that it runs through.
Regards |
There was a problem hiding this comment.
tests are currently failing and a constructor unit test should be added:
-
ODataModel (v2) constructor Unit test
https://github.com/SAP/openui5/blob/master/src/sap.ui.core/test/sap/ui/core/qunit/odata/v2/ODataModelNoFakeService.qunit.js#L110
--> check oHeaders -
ODataModel (v2) integration test
https://github.com/SAP/openui5/blob/master/src/sap.ui.core/test/sap/ui/core/qunit/odata/v2/ODataModel.integration.qunit.js#L846
--> delete X-Requested-With header -
Requestor (v4) Unit test
https://github.com/SAP/openui5/blob/master/src/sap.ui.core/test/sap/ui/core/qunit/odata/v4/lib/_Requestor.qunit.js
--> fix tests -
Requestor (v2) Unit test
https://github.com/SAP/openui5/blob/master/src/sap.ui.core/test/sap/ui/core/qunit/odata/v4/lib/_V2Requestor.qunit.js
--> fix tests
|
Hi @tobiasso85, Got fixes ready for 3/4, but could you elaborate on the first item? |
|
Since there is already a test for the constructor, and the constructor code is modified, assert.deepEqual(oModel.oHeaders, {
"Accept": "application/json",
"Accept-Language": sap.ui.getCore().getConfiguration().getLanguageTag(),
"DataServiceVersion": "2.0",
"MaxDataServiceVersion": "2.0",
"sap-contextid-accept": "header",
"X-Requested-With": "XMLHttpRequest"
});https://github.com/SAP/openui5/blob/master/src/sap.ui.core/test/sap/ui/core/qunit/odata/v2/ODataModelNoFakeService.qunit.js#L110 |
| @@ -113,7 +113,8 @@ sap.ui.define([ | |||
| "Accept" : "application/json;odata.metadata=minimal;IEEE754Compatible=true", | |||
| "OData-MaxVersion" : "4.0", | |||
| "OData-Version" : "4.0", | |||
| "X-CSRF-Token" : "Fetch" | |||
| "X-CSRF-Token" : "Fetch", | |||
| "X-Requested-With" : "XMLHttpRequest" | |||
There was a problem hiding this comment.
Why should WE do this? Shouldn't it be already done automaticall by jQuery.ajax()?
Their code says the following:
// X-Requested-With header
// For cross-domain requests, seeing as conditions for a preflight are
// akin to a jigsaw puzzle, we simply never set it to be sure.
// (it can always be set on a per-request basis or even using ajaxSetup)
// For same-domain requests, won't change header if already provided.
if ( !options.crossDomain && !headers[ "X-Requested-With" ] ) {
headers[ "X-Requested-With" ] = "XMLHttpRequest";
}
Who am I to know this better? This sound dubious to me. I am not convinced, sorry.
There was a problem hiding this comment.
It would make sense that this was indeed taken care of by jQuery.ajax(), but I didn't assume that they should. When I performed some tests I quickly noticed these headers were missing using the v2/v4 OData models.
I just did another test and it shows that these headers are present in bare $.ajax() calls, but not in ajax requests originating from UI5 v2/v4 models.
See network log: https://plnkr.co/edit/16J1TFICxbqETCzaxuZ0?preview
To whitelist your IP for the V2 CORS, click the button over at https://cors-anywhere.herokuapp.com/corsdemo
There was a problem hiding this comment.
Have you shared the correct Plunker ID? It is not doing any OData calls in my case and in the code I also cannot see why it should.
With one of our test applications I can see the header X-Requested-With: XMLHttpRequest for the batch requests.
There was a problem hiding this comment.
@uhlmannm The Plunker issues a same-origin request for its JSONModel data. I guess that's what @piejanssens was referring to.
As @ThomasChadzelek already pointed out with the code snippet, jQuery sends the X-Request-With=XMLHttpRequest header automatically, if and only if the outgoing request is a same-origin request and when the caller of $.ajax did not add the header already.
The reason for the same-origin condition is that X-Requested-With is not a CORS-safelisted header. Adding it to a cross-origin requests will therefore trigger an additional preflight request, which often is unwanted in the general case (e.g. for performance reasons or when the server is not prepared to handle it). Several frameworks therefore removed the X-Requested-With header again from their defaults (1) or limited it to the same-origin case (jQuery).
When there are already other non-safelisted headers (e.g. X-CSRF-Token) and when the server is known to allow the X-Requested-With header with CORS or when the server is in the same origin as the current page, then adding the header should be safe.
I just wonder how the ODataModel could know about the server capabilities.
|
Hi @piejanssens , after quite some discussions we decided not against this change, but instead only take parts of it; this means we will align the behaviour of OData v2 and v4 such that the X-Requested-With Header only gets sent for non-cross origin requests. The header can still be set manually though as part of the ODataModel configuration (e.g. in the manifest):
Regards |
|
Hi @tobiasso85, Since the default $.ajax behavior is only valid for same-origin requests the Plunkr was a bad example of course. I am perfectly OK with having to set custom headers for CORS requests. My real-world issue was raised from a same-origin scenario. So if I get this right, this means at the moment UI5 strips away (or initializes the full headers array) the default present header from the XHR in a same-origin scenario and this is what will be reinstated? Regards, Pieter |
Hi Pieter, I don't know if I get your question right; Regards |
In case the session has timed out and a new GET request comes in, the @sap/approuter component responds with status 200 and HTML content to store session and redirect the browser. By indicating the request originates from an AJAX call, the @sap/approuter is informed that it should return a 401 in case the session has timed out.