adding CSRF parameter in service.tx(request).run(request.query)

[karthiheyan_murugesan1]

Hi ,

Any lead on how to use service.tx(request).run(request.query) for a post call to S/4 odata.

More details

When I use service.tx(request).run(request.query) for a post call, Iam getting CSRF token invalid error in S/4 and thus 403 error in CF.

Iam able to get CSRF token with S/4 URL directly in Tcode /iwfnd/maint_service with header as [X-CSRF-TOKEN : Fetch ].

Iam not able to get CSRF token if i use post using service.tx(request).run(request.query) of SAP CAP Service. [HTTP header is not having the [X-CSRF-TOKEN : Fetch] ]

Exact question

1. How to set header parameter for getting CSRF token in [ service.tx(request).run(request.query) ] . I want to set [X-CSRF-TOKEN : Fetch] in a GET request header so i can set back CSRF token in post call.

Regards,

Karthi

[jhodel18 · Accepted solution]

I’m afraid that you are going to code the logic for that on your own. According to the documentation below:

https://cap.cloud.sap/docs/guides/consuming-services#sending-requests

the fluent API can cater to do create (POST) request, however, from my experience, it didn’t work when it starts to use the service via connectivity proxy. So what I did, is I have coded the solution my self using the axios node module — it is the same node module that cap for node.js use.

[karthiheyan_murugesan1 · Accepted solution]

thanks Jhodel .Iam exploring this https://blogs.sap.com/2019/11/13/consuming-destinations-in-cloud-foundry-using-axios-in-a-nodejs-app...

[karthiheyan_murugesan1 · Accepted solution]

Hi ,

I tried implementing a simple sap-cf-axios get method , it was working perfectly. When i call the service second time , it is failing with 407 error. What am I missing ? Any hint ?. This looks strange. It is failing alternatively .

Regards,

Karthi

[jhodel18 · Accepted solution]

There's an issue with the caching of token inside this module sap-cf-destconn. So what I did is I hacked the code to disable the passing back of the cached token and it is working fine after that (for subsequent calls). See screenshot below:

[karthiheyan_murugesan1 · Accepted solution]

Hi Jhodel,

Thanks a lot 😉 🙂 :-). I see you raised an issue for this. 🙂 .

This could be dumb question, I see you corrected the .js file of sap-cf-destconn. Assume I do not want to wait for an official fix and want to move on with the local version. How should I handle it in CAP world? Because MTA will not consider my local library and package.json will always install from the library. Is there any way I can copy the library and make as it a local one ,do some config in mta.yaml to consider my local library in deployment and refer the same in service.js .

[jhodel18 · Accepted solution]

Hi Karthiheyan,

You're welcome! About the SAP Cloud SDK, I played around it once and encountered some issues. I'm still new on this tool and haven't really taken a deep look at this. Perhaps when I have some free time, I will look into this again.

Right now I'm comfortable with my current workaround solution, but I need to work on this a little bit more to make it more elegant, what I mean by that is that the workaround solution is working when deployed to SCP, but it is not easy to test locally. Once I have made this solution more compatible with CAP, I plan to write a blog about this.

In order for you to make a local copy of the NPM delivered modules, you can create a lib folder inside your cap "srv" folder. In my case, I'm not using the module sap-cf-axios. I'm using axios + sap-cf-destconn. I copied connectivity.js in my srv > lib folder. And called it in one of my cap custom .js handlers using this syntax:

const { readConnectivity } = require("./lib/connectivity");

Note that when you specify to load a module in this way, you are loading from the local module. But if you are omitting the ./ or ../ then you are loading from a node_module folder -- like the example below:

const axios = require("axios").default;

Just bear in mind, that if the JS file you copied does call another file within that module you have to copy that JS file as well. In my case, connectivity.js is calling for tokenCache.js and that's why I copied it as well. I disabled the returning of the cache but I didn't remove all the logic that is linked to tokenCache.js. I also cannot wait for a permanent fix for the module so I opted to handle it myself in my own cap project and it is already deployed in SCP.

[karthiheyan_murugesan1 · Accepted solution]

Thanks a lot Jhodel.Sincere thanks for sharing your knowledge.

[jhodel18 · Accepted solution]

I was pumped up to finish fixing the code. By this point, it will be easy for you to consume my solution because I already published it in npmjs.com -- see below git repo, and refer to the readme documentation how to install and use it.

https://github.com/jcailan/cdse

Happy to help Karthiheyan!

[karthiheyan_murugesan1 · Accepted solution]

Thanks a lot Jhodel. I want one more greedy request :-). I think this is not considering the Location id parameter in Destination . When Destination has Location id , this is not able to identify the SCC and resulting in 503 error. I tried configuring a new connection without Location id and it is working for all subsequent calls.

Make this wish true when you have time.Thanks a lot Jhodel.

[jhodel18 · Accepted solution]

Hi Karthiheyan, no problem! Yeah, I did not include LocationId in the logic because I'm not using it, and therefore, not able to test. I've applied patch 1.0.2 -- can you try it out and let me know if it works?

[karthiheyan_murugesan1 · Accepted solution]

Thanks a lot, Jhodel. The latest update is working fine.

Regards,

Karthi

[p619793 · Accepted solution]

jhodel18 Thanks for this wonderful extension node module! Is this still an issue with the CAP's own node.js library?

Best regards.

Sumit

[carlonnheim]

Hi,

Noting for the benefit of future readers on this post that the above issue is now, at least in my case, easy to solve by setting cds.env.features.fetch_csrf = true as noted here.

Regards

//Carl

[manuel_seeger]

I had the same problem when accessing the Cloud 4 Customer OData API through an imported external service. Additionally, the C4C API doens't implement HEAD.

I solved it by modifying http-client.js of @sap-cloud-sdk . I added the following intercepter at the end of the file (L195 in version 1.28.1). Note that this is targeting C4C and might need some small changes to make it generic.

function createRequestInterceptor() {
    const interceptor = axios_1.default.interceptors.request.use(async (config) => {
        if (config.url.startsWith('/cust/')) {
            // for customer OData resources, reqrite the baseURL to point to the customer namespace
            config.baseURL = config.baseURL.replace(/\/v1\/c4codataapi/, '')
        }
        if (['head', 'get'].includes(config.method)) {
            config.headers['x-csrf-token'] = 'fetch' 
        }
        
        // intercept post/patch/delete and send a head request
        // to the same resource to fetch the CSRF token
        // the intercepter needs to be ejected before sending the head
        // request to avoid endless recursion
        if (['post','delete','patch'].includes(config.method)) {
            let tokenConfig = __assign({}, config)
            // better would be head, but our target system (C4C) doesn't implement HEAD
            tokenConfig.method = 'get'
            delete tokenConfig.data
            delete tokenConfig.headers['content-type']
            delete tokenConfig.headers['content-length']
            tokenConfig.headers.common['x-csrf-token'] = 'fetch'
            tokenConfig.validateStatus = (status) => {
                return status >= 200 && status < 300 || status == 400; 
            }
            
            try {
                axios_1.default.interceptors.request.eject(interceptor)
                let tokenResponse = await axios_1.default.request(tokenConfig)
                config.headers.common['x-csrf-token'] = tokenResponse.headers['x-csrf-token']
                const cookies = tokenResponse.headers['set-cookie']
                if (cookies) {
                    config.headers.Cookie = cookies.join('; ')
                }
                
            } catch (e){
                if (e.isAxiosError) {
                    console.log(e.response.status, e.response.statusText)
                } else {
                    console.log(e)
                }
                
            } finally {
                createRequestInterceptor()
            }
        }
        return config
    })
}
createRequestInterceptor()

Someone smarter than me can probably come up with a cleaner way to add the interceptor to the http client without having to modify the @sap-cloud-sdk library. Additionally this will request a new CSRF token before every patch/post/delete instead of caching the token.

It's an extremely simple "fix" though and for my purposes it's good enough

[gregorw]

Maybe the cdse from jhodel18 helps you.

[manuel_seeger]

Thanks Gregor, I had tried cdse but it didn't work for me and I would have to rewrite it as well to fit C4C. And honestly I find the axios interceptor a bit more elegant than rewriting the destination handling as it's completely agnostic to how axios is configured.

Anyway this works well for my use case and I meant to share this approach as an alternative.

[vansyckel]

Hi karthiheyan.murugesan1, jhodel18,

Please see the SAP Cloud SDK for such functionality.

Best,
Sebastian

[karthiheyan_murugesan1]

Thanks Sebastian, As Iam a beginner , i need more info.

Assume i want to execute a simple GET

1) I generated odata client from edmx.

2) I have my service definition in service.cds. and its corresponding implementation in service.js.

Will my service.js look like this ? Can you help with a demo GITHUB repos

import { header } from './odata_gen/z-operation-service'; //this line 1 is giving error

srv.on('READ', 'header', request => { return header.requestBuilder().getAll().execute("dest"); })

[gregorw]

Hi Sebastian, Ki karthiheyan.murugesan1,

karthiheyan.murugesan1: I would suggest you check out Consuming Services.

vansyckel: can we expect that CAP will hide this complexity from us?

Best regards
Gregor

[karthiheyan_murugesan1]

Hi Gregor ,

There is an open issue in Consuming Services, preventing us from using the POST [csrf token] method to an on-premise system [They might release in Q3/4]. Leaving us with two options

1) Node library like cdse, sap-cf-axios

2) SAP cloud SDK Here regarding SAP cloud SDK , there are very fewer blog resources for JS world in consuming external services through destination.

Regards,

Karthi

[SebastianEsch]

Hi Karthi,

in Cloud SDK you don't have to do more than provide the destination name in your call to the OData Client. Cloud SDK handles the lookup of the destination and using the Connectivity Proxy behind the scenes: https://sap.github.io/cloud-sdk/docs/js/features/connectivity/proxy-js-sdk#the-automatic-flow

const businessPartners = BusinessPartner.requestBuilder()
  .getAll().filter(BusinessPartner.BUSINESS_PARTNER_CATEGORY.equals('1'))
  .top(5)
  .execute({"destinationName": 'myDestination'});

Kind regards,

Sebastian

[vansyckel]

Hi gregorw,

Improving service consumption is on the roadmap and we'll see what we can do.

Best,
Sebastian

[Evgenii]

Hi Sebastian Esch!

The Cloud SDK for JS still might have issues with consumption of OData services from the S4/Hana on-premise system.

At least it didn't work in my case. https://github.com/SAP/cloud-sdk/issues/171

Though I can get through the proxy to the system I fail with authentication at the on-premise for some reason but when using a standard http request with defined http headers has no issues with authentication.

It could be an issue of the generated odata-client or axios which is used to send a http request to the on-premise.

Best Regards,

Evgeniy