3

I am looking at a request in SoapUI that is sending header info to a specific endpoint but I am having a hard time recreating it in ColdFusion.

Below is what the RAW request looks like in SoapUI:

>> "GET https://test-01.mywebsite.com/data_api//1.0/service/requests HTTP/1.1[\r][\n]"
>> "Accept-Encoding: gzip,deflate[\r][\n]"
>> "Authorization: Bearer A1BEC30F7E0273059E775A6A2645E273[\r][\n]"
>> "Host: test-01.mywebsite.com[\r][\n]"
>> "Connection: Keep-Alive[\r][\n]"
>> "User-Agent: Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
>> "[\r][\n]"
<< "HTTP/1.1 200 OK[\r][\n]"
<< "Pragma: No-cache[\r][\n]"
<< "Cache-Control: no-cache[\r][\n]"
<< "Expires: Wed, 31 Dec 1969 16:00:00 PST[\r][\n]"
<< "Content-Type: application/json;charset=UTF-8[\r][\n]"
<< "Content-Length: 6796[\r][\n]"
<< "Date: Fri, 13 May 2016 15:40:08 GMT[\r][\n]"
<< "Server: hws[\r][\n]"
<< "Set-Cookie: X-HR-ClientSessionId=2_10.85.12.121_1463154008475;Secure; path=/; HttpOnly[\r][\n]"
<< "Content-Encoding: deflate[\r][\n]”

I am not sure if I am not formatting the Authorization header correctly or what but any help would be great.

EDIT I got a RAW HTML output from the client which I have updated above. I am still trying to recreate that header in ColdFusion.

My New question(s): Do the "New Line" characters make a difference in the header values? Should I also add a parameter for the content type?

I did try the following:

<cfset NL="Bearer BD4DF031B24180C9338F0D9F060556A7" & Chr(10) & Chr(13)/>

<cfhttp method="get" url="https://test-01.mywebsite.com/data_api//1.0/service/requests" result="orderList">
    <cfhttpparam type="HEADER" name="Authorization" value="#NL#">
    <cfhttpparam type="Header" name="Accept-Encoding" value="gzip,deflate">
</cfhttp>
<cfset CurrentOrders = deserializeJSON(orderList.filecontent)>

<cfdump var="#CurrentOrders#">

When I dump everything from the cfhttp call I get:

struct
Charset     UTF-8
ErrorDetail     [empty string]
Filecontent     Connection Failure
Header  HTTP/1.1 200 OK Connection: close Expires: Wed, 31 Dec 1969 16:00:00 PST Date: Tue, 17 May 2016 19:23:36 GMT Server: hws Pragma: No-cache Cache-Control: no-cache Set-Cookie: X-HR-ClientSessionId=3_12.161.115.226_1463513016026;Secure; path=/; HttpOnly Content-Type: application/json;charset=UTF-8
Mimetype    application/json
Responseheader  
struct
Cache-Control   no-cache
Connection  close
Content-Type    application/json;charset=UTF-8
Date    Tue, 17 May 2016 19:23:36 GMT
Expires     Wed, 31 Dec 1969 16:00:00 PST
Explanation     OK
Http_Version    HTTP/1.1
Pragma  No-cache
Server  hws
Set-Cookie  X-HR-ClientSessionId=3_12.161.115.226_1463513016026;Secure; path=/; HttpOnly
Status_Code     200
Statuscode  200 OK
Text    NO

I am getting a 200 OK status code but still getting a Connection Failure.

Denoteone
  • 4,043
  • 21
  • 96
  • 150
  • Not sure I follow the exact issue beyond the fact that something is not working ;-) 1) First, start by dumping the complete response from cfhttp. What is FULL error message? 2) To clarify are you saying the "raw request" from SoapUI *succeeds* but cfhttp does not? 3) What does the cfhttp "RAW request" look like and what is different between the two? – Leigh May 17 '16 at 16:50
  • I will update my question with the info you mentioned above. Thank you.\ – Denoteone May 17 '16 at 16:55
  • I have added the complete output of orderList from the cfhttp request. I am having a hard time viewing the raw headers on my end because when I send my request to a local file the Authorization header throws it off because I have to add my local username and password to access the test page. Yes the SoapUI does succeed and the Raw html is above. The CFHTTP request does not succeed. If there is anything specific I can run and output just let me know. – Denoteone May 17 '16 at 18:01
  • *have to add my local username and password to access the test page.* Are you using Fiddler to debug the CFHTTP request (best) or simply sending the request to test page on your local server? – Leigh May 17 '16 at 18:12
  • NTLM, there is another hit on what may be the issue. NTLM authentication isn't the same as basic authentication. – Twillen May 17 '16 at 18:29
  • I literally have the SoapUI project I am just not sure were to look for specifics. It litterally shows the Raw request and the response. I know it is not the Auth Token because there is a specific error message if it is not correct. I have a feeling it has something to do with the format of the header I am sending. I also have access to the soapui-project.xml would it help if I shared that? – Denoteone May 17 '16 at 18:45
  • @Twillen - True, though my read on it was the server response indicated it supported both NTLM *and* Basic. I only skimmed it though, so I could be wrong. Denoteone - I did not see an answer to this one - Are you using Fiddler to debug the cfhttp request? – Leigh May 17 '16 at 19:33
  • I updated my output when I dump the cfhttp call. I removed some code above the cfhttp call which just did the call to get the auth code. The status 200 ok is something outlined as one of the responses in the soapui project xml but I am still getting the connection failure in the body of the response. – Denoteone May 17 '16 at 19:42

1 Answers1

3

It looks like you're double encrypting your security token. I modified your code so I could capture the request with Fiddler as per Leighs Answer. To get ColdFusion to send the traffic through Fiddler I modified Dmitri Pisarenko answer for http and added it to my JVM Arguments.

<cfhttp method="get" url="http://localhost/data_api/1.0/service/requests" result="orderList">
    <cfhttpparam type="HEADER" name="Authorization" value="Basic #ToBase64("Bearer 6EDC52118E164AE659EA2C772F3B9804")#">
    <cfhttpparam type="Header" name="Accept-Encoding" value="gzip,deflate">
</cfhttp>

The head I get leaving the cfhttp request is:

GET http://localhost/data_api/1.0/service/requests HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip,deflate
Connection: close
Authorization: Basic QmVhcmVyIDZFREM1MjExOEUxNjRBRTY1OUVBMkM3NzJGM0I5ODA0
Host: localhost
Connection: Keep-Alive

As you can see, the Authorization header isn't the same as what SoapUI created.

I modified the value of the Authorization param to : "Bearer 6EDC52118E164AE659EA2C772F3B9804" and I get a header with an authentication header that matches the raw header from SoapUI:

GET http://localhost/data_api/1.0/service/requests HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip,deflate
Connection: close
Authorization: Bearer 6EDC52118E164AE659EA2C772F3B9804
Host: localhost
Connection: Keep-Alive
Community
  • 1
  • 1
Twillen
  • 1,458
  • 15
  • 22
  • Yep. It looks like the value is already encoded as hex, so as Twillen said invoking toBase64 is not needed. Also, I am not sure the "Basic " prefix is needed either. – Leigh May 12 '16 at 19:27
  • Thank you Twillen for your detailed answer I am implementing the changes now and will follow up shortly. +1 – Denoteone May 12 '16 at 20:28
  • @Twillen & Leigh I updated my question with new raw html I got from the client which I have tried to update my coldfusion with the same results. I was wondering if you see anything I may be missing. Thanks. – Denoteone May 17 '16 at 16:07
  • @Denoteone What pops out is Set-Cookie. I reread the last question I answered and I think this API may also use session management, so you will need to pass back the cookie. I'm also now assuming your failing on a second request after getting an other key. I see Ben Nadel has a [write up](http://www.bennadel.com/blog/725-maintaining-sessions-across-multiple-coldfusion-cfhttp-requests.htm) on how to pass back the cookie. If this the correct assumptions I could also update my answer as well. – Twillen May 17 '16 at 16:25
  • Twillen that is correct my first request I get back some JSON which is the Auth Token you see after "Bearer". Let me look at that post about sending back the cookie. Thanks! – Denoteone May 17 '16 at 16:27
  • I have submitted a question to the owner of the API regarding the session management. I will follow up with any answer I get so that you can update accordingly. – Denoteone May 17 '16 at 16:43
  • Twillen the session and cookie information is not used in this app is the response I got. – Denoteone May 17 '16 at 18:02