This section is only applicable to third-party applications, which are integrated with main | b2b endpoints. Since the intention here is only to show how the CSRF tokens are set, the “int” endpoint with BASIC authentication is used. This simulates the scenario for main, b2b endpoints whenever JSESSIONID is used as well.
Logic apps can be configured to work with CSRF protected projections by sending the XSRF-TOKEN cookie and `X-XSRF-TOKEN header value with each protected resource call, using direct http calls.
Figure 1 shows an example Logic app, which uses the aforementioned CSRF mitigation mechanism.
Figure 1 - Logic app with CSRF
In the above Logic app a GET request is first made to retrieve metadata. (which also returns the CSRF cookie).
Then this cookie and the extracted X-XSRF-TOKEN header value is sent with all subsequent requests which manipulate protected resources.
Power apps can be configured to work with CSRF enabled projections by sending the XSRF-TOKEN cookie and the X-XSRF-TOKEN header value with each protected resource call. For this the Azure based tool called Flows is used. Again this only works with direct http calls.
Figure 2 shows an example Power app, which uses the aforementioned CSRF mitigation mechanism.
_Figure 2 - Power app that uses the CSRF mitigation mechanism
Figure 3 shows the Flow power app, used to create the entity.
_Figure 3 - Flow power app
In the above Power app Flow a GET request is first made to retrieve metadata. (which also returns the CSRF cookie).
Then this cookie and extracted X-XSRF-TOKEN header value is sent with the create request.
For more details about CSRF implementation, follow this link.