JayData oData request with custom headers - ROUND 2

依然范特西╮ 提交于 2019-12-24 03:48:12

问题


Few month back I was working on some Odata WCF project and I had some problems with parsing custom headers for token auth (apiKey).

At that time, being quite a noob (still am!), I posted this SO question: JayData oData request with custom headers

Today I am working on a new project with Jaydata Odata server and client library and this:

 application.context.prepareRequest = function (r) {
     r[0].headers['apikey'] = '123456';
 };

was working fine till I had to do a MERGE request. I found out that somehow MERGE request was overriding my headers so I investigated further.

It appears at first that in the oDataProvider.js (~line 617) in the _saveRest method the headers are not inherited:

request = {
   requestUri: this.providerConfiguration.oDataServiceHost + '/',
   headers: {
      MaxDataServiceVersion: this.providerConfiguration.maxDataServiceVersion
   }
};

but a few lines later we get:

this.context.prepareRequest.call(this, requestData);

which "should" call my own prepareRequest, but doesnt... Instead it still points to:

//Line 11302 jaydata.js
prepareRequest: function () { }, 

which of course does... nothing! Funnilly enough, when you execute a simple GET the same code supposedly on the same context instance works and points to my prepareRequest override.

I can assert with enough confidence that somehow the context between GET/MERGE is not the same instance. I cant see, however, any place where the context instance is reassigned.

Has anyone got a clue?

PS: this is NOT a CORS issue. My OPTIONS is passing fine and manually feeding the headers in oDataProvider works.

More

I followed the lead on different context instances and found something interesting. calling EntitySet.save() ends up calling the EntityContext constructor. see trace:

$data.Class.define.constructor (jaydata.js:10015)
EntityContext (VM110762:7)
Service (VM110840:8)
storeToken.factory (jaydata.js:14166)
$data.Class.define._getContextPromise (jaydata.js:13725)
$data.Class.define._getStoreContext (jaydata.js:13700)
$data.Class.define._getStoreEntitySet (jaydata.js:13756)
$data.Class.define.EntityInstanceSave (jaydata.js:13837)
$data.Entity.$data.Class.define.save (jaydata.js:9774)
(anonymous function) (app.js:162) // My save()

That explains why I get two different instances...

Hack

Replacing the prepareRequest function direcly in the class definition works, but its ugly!

for now I can cope with this:

$data.EntityContext.prototype.prepareRequest = function (r) {
   r[0].headers['apikey'] = '12345';
}; 

This works fine as long as you only need to talk to a single endpoint.

Final word based on my experience

As much as I like JayData, it is obvious that they created a monster and its getting out of their hands (poor forum, no community, half-documented,...).

I chose JD because I was lazy and wanted to keep working with my old WCF DataService. Switching to Web API seemed wrong or too much work for me.

Also as a .net dev I liked strong typing of my entities and the ability to work with a concrete model generated from the JD tools. However, in the end, I was adding confusion. Every time my server side model changed I had to fetch the new metadata and scaffold a new entityModel.

I ended up by switching to Web Api and migrated my data service layer to Breeze. And seriously! its a breeze to work with it!

The documentation is absolutely brilliant and here on S.O you can always count on Ward or Jay Tarband to reply with a very high amount of professionalism.

In the end I realize this should probably be more a wiki than a Question.....

来源:https://stackoverflow.com/questions/21689832/jaydata-odata-request-with-custom-headers-round-2

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!