I defined an integration of type "Web Services Data Actions" with a basic authentication (Username and Password)
The associated data action returns the error message "No authentication bearer token specified in authorization header
In the configuration of the data action, I tried to keep the headers empty or to define the Authorization, nothing change I always get the same error message.
The Authorization has been defined with variables or with the hard coded base 64 value, always returning the same error
For trouble shooting purpose, I defined another integration without any authentication. In the associated data action (imported from the previous one), I only defined the Authorization with the hardcoded base64 and this one is working.
Can you please tell me how the Authorization needs to be defined with basic Auth?
The error that you are reporting seems suspicious:
"No authentication bearer token specified in authorization header"
This seems to be expecting that you will have authenticated separately to get a bearer token, and then should be using that token on your request. That is exactly what the OAuth credential flow supports.
Otherwise you setup your credential with username and password and the action should be using the the standard approach to do basic authentication. If you want to see exactly what your action is doing you could use something like mockable.io to setup an endpoint and enable logging to see exactly what the data action is sending with the different configurations you mention.
The strange thing is that I can't get the basic Auth working when defining basic Auth in the integration. I made another integration defined as user defined auth with the same username and password, and that one is working fine when defining the Authorization header as Basic $encoding.base64("${credentials.Username}:${credentials.Password}")
I will try mockable.io to see the difference, thanks for the hint.
I found the root cause, my password management app was overwriting the user name when I was hitting the "tab" key to go to the next field. I did the manipulation twice with the integration setup as basic Auth ... and faced the same behaviour twice without seeing it.
Thanks to your hint, I was using mockable.io and saw that the authorisation header was different than expected.
Thanks for you hint and your responses Jason