Technical Articles
Cloud Integration (CPI) Inbound http 401 error
When dealing with Cloud Integration and specifically inbound requests and messaging processing, sometimes an http error is occurring. To help customers to quickly address these issues, we have released few resources to help our customers on knowing how to debug it and address it.
- The first one is a Guided Answer, Cloud Integration (CPI) Inbound 401 errors. The purpose of this Guided Answer is to address what could cause http 401 error and how to debug it
- The second one is a WIKI, “How to check Cloud Integration Logs for errors”:
The purpose of this WIKI is to help investigate the logs entries related to inbound request and message processing errors in Cloud Integration tenants
With such resources, the administrator should be able to debug and address http 401 error issues and be able to look at the trace logs in order to debug it.
Ali,
It would definitely help with the debugging during inbound auth issues. i think what's lacking is the ability to check the oauth logs. By this i mean if the client is sending the incorrect client id or secret to retrieve the token (https://xyz.authentication.us21.hana.ondemand.com/oauth/token) he would be getting back an HTTP 401 error. I believe there arent any logs visible on the CPI side which we can check to confirm that the sender is sending the wrong client id or client secret.
Regards,
Sumit
Thank you Sumit!!! I really appreciate your feedback. I will look into this and see what it can be done.
Hi Sumit,
If a wrong client id or secret is sent to this token url, besides the 401 error code, the response body should contain the detailed error {"error":"unauthorized","error_description":"Bad credentials"}.
If the client side log doesn't show this body, then client side should improve the log output. Or you can use other client tools (postman for example) to simulate the error and check the response body.
Best regards,
Susan
Hi Susan,
Thanks for the reply, indeed the client will get that response. My point was still it might be better if we could see some logs on the CPI side to confirm that the request did hit the CPI tenant and it was rejected because of incorrect credentials. Similar to how we can see in the HTTP access log for basic auth.
Regards,
Sumit
Hi Sumit,
Basic auth and oauth is different authentication method. When you mention CPI tenant here, in oauth flow, it includes two parts (xsuaa and CPI runtime)
if the access token is not obtained successfully, I think the CPI runtime endpoint is not hit. No log will show in http access log.
Best regards,
Susan
Hi Susan,
Thanks for taking the time out to reply . I do understand how it works, but my point is if we can get some kind of read access to the logs which can show us that the access token request was made and that the 'server' returned back the unauthorized error.
I didnt mean to display the access token unauthorized error to be displayed in the http access log. I just meant that if the HTTP error for the CPI end point is visible in the http access log then its good that we have access to some kind of logs where the oauth token error is also visible.
Regards,
Sumit
Hi Sumit,
Authorization server (XSUAA) log can't be accessed by customer. It's somehow like you provide a wrong user and password to logon a web site and the site will show warning “authentication failed”, etc.
If you provide a wrong access token to CPI runtime, then CPI log should record this.
Best regards,
Susan