Closed renanwilliam closed 8 years ago
I think that can be solved with something like that:
var oSharedMethod = ModelClass.sharedClass.find('find', true);
ModelClass.checkAccess(req.headers.authorization,"ModelName",oSharedMethod, loopback, function(param1, param2){
console.log(param2);
});
I think something is missing.
OData services can now be protected with authorization functionality as described in loopback documentation. Hiding methods is not supported yet, but ACLs work. We will write a tutorial next that shows to use security with n-odata-server.
Implemented functionality in odata.ts. Cause we mainly leverage standard loopback functionality it should work for all use cases.
I think that we have a problem when sending the token in Authorization header. I tried but the token is not set in req.accessToken, it is only in headers.authorization
I had a look at your changes and I would like to undo your change regarding AccessToken in odata.ts. The provisioning of the AccessToken in http request can be done by loopback configuration. This is documented somewhere in the loopback documentation and I think, cause it’s the recommended way, this should also be our way (relying on framework functionality as much as possible). I’m talking about this change
//Needs to instantiate the AccessToken Model first
this.getAccessTokenInstance(req, res).then(() => {
I think it's sufficient to add this line to your middleware.json file directly after the "initial" and "session" sections
"auth": {
"loopback#token": {}
},
This is documented here
If you need to access the AccessToken and other context information in your application you can use the loopback-context
module. This is documented here
Can you please undo your AccessToken changes and test it with the above mentioned setting?
If we have a end-point with protected access by ACL it's by-passed in OData requests
Loopback API request
n-odata-server request