• 114 comments

  •   •   about 9 years ago

    did it do the trick?

  •   •   about 9 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.

  •   •   about 9 years ago

    I guess that is instead of thank you. No problem, good luck.

  •   •   about 9 years ago

    Can you capture raw data you send?

  • Manager   •   about 9 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.

  •   •   about 9 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?

  •   •   about 9 years ago

    Unfortunately I am not working with PHP. Sorry

  •   •   about 9 years ago

    @momcorp Willingness to help doesn't man to give away my little secrets :-) I think you can use both.

  •   •   about 9 years ago

    @momcorp Can you capture and show raw data you send? Wireshrak, Fiddler?

  •   •   about 9 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.

  •   •   about 9 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 :-(

  •   •   about 9 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?

  •   •   about 9 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.

  •   •   about 9 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.

  • Manager   •   about 9 years ago

    Hi there,

    Sorry about the delay - we're working with the test lab team and will hopefully have a fix soon.

    Lindsay

  •   •   about 9 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

  •   •   about 9 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.

  •   •   about 9 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.

  •   •   about 9 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

  •   •   about 9 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.

  •   •   about 9 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".

  •   •   about 9 years ago

    may be your access token gets corrupted too somehow?

  •   •   about 9 years ago

    Finally there is no questions about this one :-)

  •   •   about 9 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

  •   •   about 9 years ago

    can you show your full request including parameters as shown above?

Comments are closed.