IBP Planning Data API X-CSRF-Token

[#1]

Hi Experts,

I am trying to configure a Service Task for a workflow on SAP Business Application Studio that would post data to IBP using OData. The OData API being used is the IBP Planning Data API Service.

To be able to do this I need a x-csrf token, but have found no way to get that token with out using a separate request and getting it from the header. Is there a path for the API available that would return the token or is going through the header the only way?

Regards,

Alex

[tobias_breyer · Accepted solution]

Hi Alex,

the automatic X-CSRF-Token retrieval via the "Path to XSRF Token" is a mechanism that has broad support in many SAP APIs. Maybe also in the Planning Data? In that case, you should check whether there is an API (take the simplest/fastest possible) that runs in the same context (authentication realm) as the end-point of the modifying API call. In many cases, the end-point of the modifying HTTP method also supports GET and returns the X-CSRF-Token when requested. For example, the workflow service itself has an "xsrf-token" endpoint just for this purpose, i.e. to have a very cheap and clearly-named end-point without further side-effects. This means, try to avoid end-points that induce heavy processing for the simple task of delivering the CSRF token, if possible.

Maybe that helps to find a suitable end-point.

Regards,

Tobias

[former_member761670 · Accepted solution]

I have not been able to find any documentation that suggests the token can be passed anywhere other than the header. Is there a way to access the header of a response so the token can get passed in or can the "Path to XSRF Token" mechanism read the token from the header?

[tobias_breyer · Accepted solution]

Hi Alex,

the Workflow service mechanism for CSRF-tokens works with the defacto standard header for that, called "X-CSRF-Token". I guess the only thing you need to confirm in IBP documentation is whether IBP itself uses that one (but it is quite standard in SAP software).

Workflow service executes a separate call to the "Path to XSRF Token", but with the same authentication (cookies and all), setting the "X-CSRF-Token: Fetch" header and expecting a suitable token value on the response "X-CSRF-Token" header. This value in turn is provided on the "productive" call ("Path" two lines before), again as the "X-CSRF-Token" header.

So there is usually no need to be able to access a header of a response for the CSRF token, as the quite standard approach is implemented by Workflow Service.

The separation of the two calls is done to allow calling faster end-points for the token and possibly cover some more edge cases. But as long as IBP supports the X-CSRF-Token concept overall, as described above, I see no obstacles.

Also refer to

https://ga.support.sap.com/dtp/viewer/index.html#/tree/2622/actions/36618:36734:37154:37155:40440

for some more conceptual explanations that might help you.

Regards,

Tobias