I don't understand why the service would consistently respond with HTTP 200's even for bad requests. I'm also unsure why an official hasn't answered the question.
I've heard back from Affinity and apparently the Test Lab was restarted last night (Tuesday, Oct. 22) - if this is still a problem let me know and I'll pass on the message.
From my experience this usually happens when the access code is wrong. Yes, the test lab should catch that but it doesn't. Do you have fiddler or wireshark on your PC?
You are still using self-signed certificates. That requires some workaround which is not so desirable. For the public system you probably could provide a cert signed by authority :-(
I am having the exact same issue at the moment. Keep getting 200 OK instead of any feedback. We are using a self-signed certificate also so I dont know if that is the issue.
Is there any solutions that we could try at the moment?
I am not sure what fix should be done as the feature works. The part which doesn't work is reporting an error if something is wrong but if you send correct data you will get back a token. My concern that "fix" you are going to implement may break existing working system which is highly not desirable
What workaround you are talking about? It works exactly according to spec except "authorization_code" with underscore. I don't have a problem changing that but it doesn't seem to be the problem. May be Lindsay will be more specific of what exactly they are fixing. One more note. The submit period is already started. I am about to submit my app in few days and I don't think that breaking something will be fair to people who already submitted their apps.
ok, guys. Here is how I can help you. I created Public Company, I created Public App for Public company. Then I authorized the app and captured all related to the issue packets.
1. You request data custodian web site with your client id
GET https://greenbutton.affsys.com/auth/signin.jsp?client_id=id-7ab09729-067f-43e3-a170-1ddec2dec22c&redirect_uri=http://energateinc.com HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Accept-Language: en-CA
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/6.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0E; .NET4.0C)
Host: greenbutton.affsys.com
Connection: Keep-Alive
Cookie: JSESSIONID=qdw1QZTNn82lsE6Jbmr05+9z.undefined; CMSPreferredCulture=en-US; VisitorStatus=11058624297; __utma=110731093.442451228.1381875474.1381875474.1381875474.1; __utmz=110731093.1381875474.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); _ga=GA1.2.442451228.1381875474
Response is the web page of data custodian for authorization.
After your "redirect_uri" is called with "authorization code". In my case it is http://energateinc.com.
You should intercept that and extract "code"
2. Ask for authentication token providing code from previous request and Basic authorization in form of
"client_id:client_secret".
request.Headers.Add("Authorization", "Basic " + Convert.ToBase64String(System.Text.ASCIIEncoding.ASCII.GetBytes(string.Format("{0}:{1}", client_id, client_secret))));
Note that redirect_uri must match redirect_uri from the previous step.
Scratch that. Turns out my access_key was being truncated silently (thanks MySQL). I'm now able to make requests, but get back "Request #1057 rejected; user not authorized".
114 comments
Yuri Shteinman • about 10 years ago
did it do the trick?
Dan Zrobok • about 10 years ago
I don't understand why the service would consistently respond with HTTP 200's even for bad requests. I'm also unsure why an official hasn't answered the question.
Yuri Shteinman • about 10 years ago
I guess that is instead of thank you. No problem, good luck.
Yuri Shteinman • about 10 years ago
Can you capture raw data you send?
Lindsay Archibald Manager • about 10 years ago
I've heard back from Affinity and apparently the Test Lab was restarted last night (Tuesday, Oct. 22) - if this is still a problem let me know and I'll pass on the message.
Yuri Shteinman • about 10 years ago
From my experience this usually happens when the access code is wrong. Yes, the test lab should catch that but it doesn't. Do you have fiddler or wireshark on your PC?
Yuri Shteinman • about 10 years ago
Unfortunately I am not working with PHP. Sorry
Yuri Shteinman • about 10 years ago
@momcorp Willingness to help doesn't man to give away my little secrets :-) I think you can use both.
Yuri Shteinman • about 10 years ago
@momcorp Can you capture and show raw data you send? Wireshrak, Fiddler?
gellis519 • about 10 years ago
Affinity just indicated that there some SSL related issues with the Test Lab. We will confirm that full functionality has now been retored.
Yuri Shteinman • about 10 years ago
You are still using self-signed certificates. That requires some workaround which is not so desirable. For the public system you probably could provide a cert signed by authority :-(
Rashaad Ramdeen • about 10 years ago
Hi there,
I am having the exact same issue at the moment. Keep getting 200 OK instead of any feedback. We are using a self-signed certificate also so I dont know if that is the issue.
Is there any solutions that we could try at the moment?
Yuri Shteinman • about 10 years ago
You can try to capture the request you send and post it. People may analyze it and tell you what is wrong with it.
Dan Zrobok • about 10 years ago
Guess we'll just assume this doesn't work at all and no one from the challenge cares enough to fix it?
The issue has been open for a long time with no resolution.
Lindsay Archibald Manager • about 10 years ago
Hi there,
Sorry about the delay - we're working with the test lab team and will hopefully have a fix soon.
Lindsay
Yuri Shteinman • about 10 years ago
I am not sure what fix should be done as the feature works. The part which doesn't work is reporting an error if something is wrong but if you send correct data you will get back a token. My concern that "fix" you are going to implement may break existing working system which is highly not desirable
Dan Zrobok • about 10 years ago
If it's not working according to the spec, then it needs to be fixed and your 'workaround' would also need to get fixed. Seems clear to me.
Yuri Shteinman • about 10 years ago
What workaround you are talking about? It works exactly according to spec except "authorization_code" with underscore. I don't have a problem changing that but it doesn't seem to be the problem. May be Lindsay will be more specific of what exactly they are fixing. One more note. The submit period is already started. I am about to submit my app in few days and I don't think that breaking something will be fair to people who already submitted their apps.
Yuri Shteinman • about 10 years ago
ok, guys. Here is how I can help you. I created Public Company, I created Public App for Public company. Then I authorized the app and captured all related to the issue packets.
1. You request data custodian web site with your client id
GET https://greenbutton.affsys.com/auth/signin.jsp?client_id=id-7ab09729-067f-43e3-a170-1ddec2dec22c&redirect_uri=http://energateinc.com HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Accept-Language: en-CA
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/6.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0E; .NET4.0C)
Host: greenbutton.affsys.com
Connection: Keep-Alive
Cookie: JSESSIONID=qdw1QZTNn82lsE6Jbmr05+9z.undefined; CMSPreferredCulture=en-US; VisitorStatus=11058624297; __utma=110731093.442451228.1381875474.1381875474.1381875474.1; __utmz=110731093.1381875474.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); _ga=GA1.2.442451228.1381875474
Response is the web page of data custodian for authorization.
After your "redirect_uri" is called with "authorization code". In my case it is http://energateinc.com.
You should intercept that and extract "code"
GET http://energateinc.com/?code=eyJhbGciOiJSUzI1NiJ9.NjI1YWZiNmMtMzdhMS00NzdmLWI3ZTMtNmNhNzc0YzQ1NGVmMTM4NDI3ODg2MDcwNg.B8WRG_hKHc_xSzQdu1rADCPqVTtprnarP3Rdyg3T_7uJ__z7rq47TX-eqmhmwTjBmki8RajLECmQ9Z5nT7dAq3ojlqwwnJP6dBRfq8pYvzZ5dgNRf5UI8dEYzoLSUYrX-FVN35ShKusUsD3xJH9fOXl2hVV1iAk1ugFtPlkp8js HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Pragma: no-cache
Accept-Language: en-CA
Cookie: __utma=1.1902519387.1381933969.1384210023.1384278532.32; __utmz=1.1381933969.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=1.2.10.1384278532; CMSSESSID00535083=0e3bc8ec74c9078abd3ea24db27045b9; __utmc=1
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/6.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0E; .NET4.0C)
Host: energateinc.com
Connection: Keep-Alive
Cache-Control: no-cache
2. Ask for authentication token providing code from previous request and Basic authorization in form of
"client_id:client_secret".
request.Headers.Add("Authorization", "Basic " + Convert.ToBase64String(System.Text.ASCIIEncoding.ASCII.GetBytes(string.Format("{0}:{1}", client_id, client_secret))));
Note that redirect_uri must match redirect_uri from the previous step.
POST https://greenbutton.affsys.com/auth/j_oauth_resolve_access_code?grant_type=authorization_code&code=eyJhbGciOiJSUzI1NiJ9.NjI1YWZiNmMtMzdhMS00NzdmLWI3ZTMtNmNhNzc0YzQ1NGVmMTM4NDI3ODg2MDcwNg.B8WRG_hKHc_xSzQdu1rADCPqVTtprnarP3Rdyg3T_7uJ__z7rq47TX-eqmhmwTjBmki8RajLECmQ9Z5nT7dAq3ojlqwwnJP6dBRfq8pYvzZ5dgNRf5UI8dEYzoLSUYrX-FVN35ShKusUsD3xJH9fOXl2hVV1iAk1ugFtPlkp8js&redirect_uri=http://energateinc.com HTTP/1.1
Content-Type: application/atom+xml
Authorization: Basic aWQtN2FiMDk3MjktMDY3Zi00M2UzLWExNzAtMWRkZWMyZGVjMjJjOnNlY3JldC1kYzI2MTc5NC05ZjY0LTRkNjMtODlmYS0xNzIwMmRjNjhiY2U=
Host: greenbutton.affsys.com
Connection: Keep-Alive
Response should be as below. Extract tokens.
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json
Content-Length: 776
Date: Tue, 12 Nov 2013 17:54:20 GMT
{"access_token":"eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5Mi5mMDhkYWI1YS01NGUzLTRkMDctYWZhOC03NDcxZmY3ZmQ4OTUiLCJhdWQiOiJjb21tZXJjZSIsInBybiI6ImJyZXR0QGRhdGFjdXN0b2RpYW4uY29tIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX19.QL_nBiytaeSC5LvKTS_CQM0AhLCgfJj6qEue1HtaLgNeJ6ETV1Ip-uy5hAAbW1zjgefvGksr9XjoAHqQf9O2mpjQcUXvPd5YZApP1NA-MuYCKv07y0yUM3rqA1chuFxH24p8ARpjZAUQK-KE0Ee2A8osHCBqMTKz4IZGRIxX5aU","refresh_token":"eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5My43OTNmMGNlNC01MGUyLTQ1NjgtOGY5NS0xYTZmYmFiMGM2MGYiLCJhdWQiOiJjb21tZXJjZSIsInBybiI6ImFkbWluIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbImFkbWluIl19fQ.Fv1AwJu9O_Aar6XxUSJ-cK6d3z9QDg5H0j_YBbZDLwnYHxaT1lgnRXPQmtXk0v9En015V5JX8tcx3c1am3DHWuuDJ74N_wFohPrPB3EcdpgfuH2GecyNamxR6V62zezXq4EinfSt4oczSaiEPRCd7m6YI8PFlrYM-wZ9iEfe3II","token_type":"bearer"}
Please let me know if that helped
Chris • about 10 years ago
I seem to be having the same empty 200 Response issue for any request after getting back an access_token and refresh_token.
For example, hitting the /ldc/api/v1/ReadAuthorizationStatus endpoint, I get the following:
Request headers:
GET /ldc/api/v1/ReadAuthorizationStatus HTTP/1.1
Host: greenbutton.affsys.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiIxNjguY2VhNTU1ZWYtODgzYS00MWYzLTg4MDUtNTAzMzgxZDE2ZjA5IiwiYXVkIjoiY29tbWVyY2UiLCJwcm4iOiJqYWVsQGRhdGFjdXN0b2RpYW4uY29tIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX19.M6fn064lwGnc_avzSlVSDMFsEKafJrXsNDXOFoi_50-tH3BDEnlp-etie
User-Agent: Guzzle/3.7.4 curl/7.22.0 PHP/5.3.10-1ubuntu3.8
Response:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Wed, 31 Dec 1969 19:00:00 EST
Transfer-Encoding: chunked
Date: Wed, 13 Nov 2013 04:37:17 GMT
Content-Length:0 / empty responseBody.
Chris • about 10 years ago
Scratch that. Turns out my access_key was being truncated silently (thanks MySQL). I'm now able to make requests, but get back "Request #1057 rejected; user not authorized".
Yuri Shteinman • about 10 years ago
may be your access token gets corrupted too somehow?
Yuri Shteinman • about 10 years ago
Finally there is no questions about this one :-)
Bianca Sayan • about 10 years ago
I have the exact same response as unclek (200 OK but no body). Does anyone have any suggestions?
Host: greenbutton.affsys.com
Accept: */*
Content-type: application/atom+xml
Authorization: Basic aWQtNDBjZGVkMjEtZTU4OS00ZTg1LWJiZWUtNThkMWU2YzNjZGI4OnNlY3JldC1lYWE3NWEzNy1hNGUxLTQ5MzAtOTE0Ni0wZWY1ODlkNTM4NWY=
Content-Length: 349
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
Date: Mon, 25 Nov 2013 03:21:43 GMT
Connection #0 to host greenbutton.affsys.com left intact
Closing connection #0
Yuri Shteinman • about 10 years ago
can you show your full request including parameters as shown above?