DSProductInventory error: You are not authorized to retrieve the orderings made by the user X about business-api-ecosystem HOT 9 CLOSED

I think that this problem is generated for the same reason (different hrefs) as #18

from business-api-ecosystem.

Still with the issue, after modifying server property in apis-conf/settings-properties file from http://proxy.docker:8004/ to http://[DOCKER_MACHINE_HOST]:8004/

Below the proxy log (To test I used postman from my local computer):

2018-05-16 15:21:19.013  - WARN: Server - 51f49039-dcec-4ed2-8ed3-7f0f18ebb217 - ::ffff:10.38.0.1 - Anonymous - GET: /DSProductInventory/api/productInventory/v2/product?status=active&relatedParty.id=jcarnero - Token 6451599ae38e74508a6c929a6bdcb54a895aff80 is from a different app
2018-05-16 15:21:19.046  - WARN: TMF - 51f49039-dcec-4ed2-8ed3-7f0f18ebb217 - ::ffff:10.38.0.1 - f8297ebc-4a60-4a43-9d74-cec472bbc01f - GET: /DSProductInventory/api/productInventory/v2/product?status=active&relatedParty.id=jcarnero - Pre-Validation (DSProductInventory): You are not authorized to retrieve the orderings made by the user jcarnero
2018-05-16 15:21:19.052  - WARN: Server - 51f49039-dcec-4ed2-8ed3-7f0f18ebb217 - ::ffff:10.38.0.1 - f8297ebc-4a60-4a43-9d74-cec472bbc01f - GET: /DSProductInventory/api/productInventory/v2/product?status=active&relatedParty.id=jcarnero - Status: 403

from business-api-ecosystem.

Ok, I am reviewing the code which validates inventory permission to see if if the is a bug with user validation

from business-api-ecosystem.

To add some info, I'm using a token different from the one that the marketplace has (as I'm accessing the http api through an external app). That's why I'm getting the first warn:

Token X is from a different app

from business-api-ecosystem.

um, that should'n be a problem, the BAE detects that the token is for an external application and uses the refresh token of the last session to obtain valid user info for the BAE app

from business-api-ecosystem.

Just a question, can you access to other protected information?
For example to the ordering API, etc

from business-api-ecosystem.

Well reviewing the code, the error happens when the query string (filter) relatedParty.id is different from the req.user.id which is populated using the information of the user given by the IDM.

According to the error message you are facing, relatedParty.id = jcarnero

So, is it possible that the access token you are sending to the BAE belongs to a user different from jcarnero?

from business-api-ecosystem.

Ok, I think I found the problem.

Indeed if I remove relatedParty.id I don't get the error. The same happens wih ordering API.

jcarnero is the user name on the IDM, and it also appears on the top right corner of the web interface of the BIZ. In the old IDM v5 displayName and id properties returned the same value, but in IDM v7 id returns a hash code.

Following your previous comment, if I do relatedParty.id=jcarnero it fails, but if I do relatedParty.id=f8297ebc-4a60-4a43-9d74-cec472bbc01f it works!

Summarizing, I think that to resolve this issue, docs should be modified to specify that relatedParty.id doesn't use the user name any more, and instead the IDM id user which is a code (something like that, to prevent confusions with old IDM v5)

from business-api-ecosystem.

buf, v6 used the username as ID of the user, so the BAE uses the username as id. This change in the IDM v7 is going to be weird in new deployments (since the hashes will apear in places the user will expect their username) and a real problem in migrations. I mean the failure is going to happen when migrating from v6 to v7 in a working BAE instance

from business-api-ecosystem.