Hi,
I am trying to connect to an external REST service which uses Basic Authentication. I have followed the tutorial on adding Remote Web Service, including ticking the “Pass from Client” box in the service config, but it would seem my Authorization header is not being passed to my external REST service.
I have tested this using requestb.in and when I send my request direct it appears with all of the required headers, but when sent via DreamFactory it strips the headers off.
Can anyone help with this?
Thanks,
Jon
I found the same. We solved it rather inelegantly like this, putting basic authentication in the URL
https://xxxBQokikJOvBiI2xxxxxxxx:@api.stripe.com/v1/
Where the xxx… is the the authentication parameter. But I too believe this to be a bug. This will work for Basic authetication but if other params need to be in the header this could pose a problem.
spoke with our engineering team about this last week. They have developed a fix, and it will be released at the completion of this sprint, which is scheduled for the end of the month.
Hi Drew,
Thanks for the update - I know it’s on the 2nd of Feb but any news on the release date for the fix?
Jon
Yes. version 2.1.0 shipped over the weekend. This fix is included.
Sorry I found the update moments after typing my previous message!
I’ve just updated to version 2.1.0 and I’m now getting an error trying to use any remote service (including those that don’t have Basic Authentication):
“message”: “Argument 1 passed to DreamFactory\Library\Utility\ArrayUtils::get() must be of the type array, null given, called in /opt/bitnami/apps/dreamfactory/htdocs/vendor/dreamfactory/df-rws/src/Services/RemoteWeb.php on line 216 and defined”,
any ideas?
Jon
Hi,
Ok I found out from this forum post: Error on service after upgrading to 2.1 there is a bug that causes the error previously mentioned - which I have followed and the error has gone.
However, despite upgrading to 2.1 the original problem still remains - HTTP headers are NOT passed across to remote web services, even when they have a fixed value (or a client supplied value; i.e. Basic Auth).
Can this be looked at as it is now holding up a project from going live.
Thanks,
Jon
Hi Jon. I’m doing some troubleshooting to validate the issue, and I’ll give you an update as soon as I have one.
Fixed.
For real this time. =)
If you follow the documented update instructions on the wiki, the DreamFactory version will not change (still 2.1,) but the df-rws repo will be updated to version 0.2.2 which has the fix for this issue.
You can confirm that you have the updated repo by checking the vendor/dreamfactory/df-rws/CHANGELOG.md file
Hi Drew,
I hate to be the bearer of bad news but it still doesn’t work 
I’ve confirmed that the df-rws version is 0.2.2, but when I send a request to requestb.in the Authorization header (or any header) is stripped from the request.
Is there anything else I can provide you with to assist in resolving this issue?
Thanks,
Jon
Jon, if I understand correctly, you’re passing the Authorization header from the client, but it’s not intended to provide DreamFactory authorization – it needs to go on to the Remote Web Service?
While generally speaking, I’m not having any trouble passing headers from the client to the RWS, the Authorization Header is not being passed on. I would suspect this is because DreamFactory is trying to use the Authorization Header being passed internally for authentication.
I’m not totally sure, so I was going to talk with an Engineer, but I wanted to make sure I understood your use case.
Hi Drew,
Yes this is my use case.
I can also confirm that the “Content-Type” header is being passed from the client, however I am experiencing some strange behaviour.
When I hard-code the authorization header I can hit my backend successfully, however it is not returning the correct data format. My backend should return JSON data (based on the url ending with “.json” and having the “Content-Type” header set to “application/json”) - which it does when I call it directly. However when I call it via DF, with exactly the same request, I get an HTML rendered page which is the expected response if I were to hit the backend service without the Content-Type header or without appending “.json” to the URL.
It would appear that the above problem has now resolved itself (bizarrely!) but I’m now facing an issue with passing url parameters across to my backend (i.e. f.clientId, f.contractorName, f.status, etc. as filter parameters for list endpoints).
This leads me to believe that DF is not passing on URL parameters with certain characters in the name.
Jon