We have faced a problem with using REST sender with client credential flow and when investigating it was found that the problem is with the token fetching request.
IFS is sending client id and secret in two places, As basic authentication in the header and the url encoded request body.
Seems sending the client secret in the body is faulty.
Is this a bug or is there any workaround to not to include the client secret in the token payload.
Issue was found in IFS Cloud 22R2 but we observed same problem in Apps10 UPD 16 as well
Best answer by Charith Epitawatta
Hi @dsj, @kvbe,
This is now fixed in IFSAPP10 UPD22 via patch ID 167255. This patch introduces a new property to control whether the client credentials will be sent in the request header or the body or both.
Property - ifs.includeClientCredentials
Expected values - body|header|both
Eg: ifs.includeClientCredentials: header
You can add the property in following 2 ways.
Add it to the ifs.properties file located in \\<IFS_HOME>\instance\<InstanceID>\conf directory.
Add it to J2EE server properties via the IEE client as described in this documentation.
This is now fixed in IFSAPP10 UPD22 via patch ID 167255. This patch introduces a new property to control whether the client credentials will be sent in the request header or the body or both.
Property - ifs.includeClientCredentials
Expected values - body|header|both
Eg: ifs.includeClientCredentials: header
You can add the property in following 2 ways.
Add it to the ifs.properties file located in \\<IFS_HOME>\instance\<InstanceID>\conf directory.
Add it to J2EE server properties via the IEE client as described in this documentation.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.
