Announcement

Collapse
No announcement yet.

Calculating Verifiable HashResponse

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Calculating Verifiable HashResponse

    I'm working on a form and we're trying to get get the postback hashresponse to match what I'm calculating, however everything I do can't seem to generate the proper sha1 hash, and I can't get it working.
    So the final redirect url winds up with (SHA1)
    Code:
    [DomainName]/index.php?on=1403241635395841111&vg=0aa80907-7d86-4d65-a3b6-e675d10793a7&au=9cbd17&gn=e9f46fb6-9385-41a7-a693-dbd19066892e&hashresponse=ZGZjMzgxMjlmNDQxMzc4NGE3M2Y4ODc5NDZhOGJkNTk5NGJkODhmZQ==&RefID=website
    so according to the documentation http://manual.clickandpledge.com/Por...PI_Information
    my string to hash is "[XXXXXX][1403241635395841111][25]" (XXXXXX is our secret word and $25 is the donation)

    So if I run that through the Hashcode function from the forums http://forums.clickandpledge.com/showthread.php?t=660
    I Get a59f8244cd58b2ff552c2f94cce60aebeb037452

    And when I run the returned hashresponse through it
    I Get ccae39caa7af1e9096500ccdbb7546f39916bbff

    Can you point me in the right direction as to what I'm missing?
    Last edited by Simon; 03-24-2014, 04:37 PM.
    Simon Jensen
    KELL Partners

  • #2
    Good day Simon,

    Here are the 2 issues with what you are doing:
    1. The [25] should be [25.00] to include pennies. So please change it to include the period and 00
    2. In the .NET example we show this but in the PHP it is missing - the Hashcode is also encoded in your reply to help with possible characters that may cause issue in the URL. You need to encode your hashcode before doing the comparison. You may want to use a site such as: http://www.base64decode.org/ for testing.

    If you do the above two corrections then your hashcode will be: ZGZjMzgxMjlmNDQxMzc4NGE3M2Y4ODc5NDZhOGJkNTk5NGJkOD hmZQ==

    which matches ours.

    Test it and let us know if it works for you.
    Regards,
    Click & Pledge Support Department

    On Salesforce? Help us by rating our app: Click & Pledge Donor Management on AppExchange

    Join us @ the educational webinars: https://clickandpledge.com/webinars/
    Live Support available Join between 3:00 - 3:30 p.m. ET Monday - Thursday: https://clickandpledge.com/webinars/
    Are you on Salesforce? Join us at the Power of Us Hub: https://powerofus.force.com/0F980000000CjpC

    Comment


    • #3
      perfect that did it.
      here's a small version of the PHP function for future reference that just accepts a string passed to it.

      Code:
      function hashcode($stringToParse){  return base64_encode(sha1(utf8_encode($stringToParse)));}
      
      // and a sample to test against 
      
      $hashResponseFromCP =  "OTgxY2JlZjJmMGJlY2FkMGU4NDczN2JjM2Y2MDUzY2Y3MTkzZWI3OA==";
      
      // Our calculated String
      $s = "[xxxxx][1403241635395841111][25.00]";
      if (hashcode($s) == $hashResponseFromCP){
          echo "match";
      }else{
          echo "nomatch";
      }
      Thanks.
      Simon Jensen
      KELL Partners

      Comment


      • #4
        Thanks Simon,

        I will have that added to the manual.
        Regards,
        Click & Pledge Support Department

        On Salesforce? Help us by rating our app: Click & Pledge Donor Management on AppExchange

        Join us @ the educational webinars: https://clickandpledge.com/webinars/
        Live Support available Join between 3:00 - 3:30 p.m. ET Monday - Thursday: https://clickandpledge.com/webinars/
        Are you on Salesforce? Join us at the Power of Us Hub: https://powerofus.force.com/0F980000000CjpC

        Comment


        • #5
          is something going on with the backend? The hashes that I'm getting back are matching only occasionally.
          The hashes being passed back from portal.clickandpledge.com don't always end in the == yet my calculated hashes always do.
          I've made a sample donation page here: https://kellpartners-sj--developer-e...nate?test=true

          and that posts to a super simple processor page. http://kellpartners.com/development/testHashCode2.php

          So far the passed hash code is has been valid ~15% of the time, and since my calculated hashes always look similar, yet the CP passed hash seems to be changing in length, I can only assume there's something going on in the backend that's calculating the CP hash? Because according the the SHA1 specification it always returns the same length hash.
          Last edited by Simon; 04-18-2014, 06:03 PM.
          Simon Jensen
          KELL Partners

          Comment


          • #6
            Hi Simon,

            Strange - since this works well in our own codes.

            How can your hash code always look similar? Don't you include the amount?

            [SecurityCode][Order Number][Amount]

            the hashcode uses the order number and the amount and as such it is not possible for it to always be the same. Even if the amount is the same the order number is always different so the hashcode has to, by design, be different each time.

            Please post your order number so we can review the XML.
            Regards,
            Click & Pledge Support Department

            On Salesforce? Help us by rating our app: Click & Pledge Donor Management on AppExchange

            Join us @ the educational webinars: https://clickandpledge.com/webinars/
            Live Support available Join between 3:00 - 3:30 p.m. ET Monday - Thursday: https://clickandpledge.com/webinars/
            Are you on Salesforce? Join us at the Power of Us Hub: https://powerofus.force.com/0F980000000CjpC

            Comment


            • #7
              By 'Similar' I meant they're always returning the same length string(56 chars) that ends in == , and yes I am including the amount. Whereas the returned hashresponse sometimes doesn't end in == and the length of the hash seems to be changing randomly.

              here's a couple samples of the responses I get and the hashes (2 that return 52 char hashes that don't work and 1 56 character hash that does) these have the ordernumber, secret code and amount in them so you can check as well.

              http://kellpartners.com/development/...YTFk&RefID=Web

              http://kellpartners.com/development/...MWI5&RefID=Web

              And One that works where the returned hash from CP is the proper 56 characters long

              http://kellpartners.com/development/...OA==&RefID=Web
              Simon Jensen
              KELL Partners

              Comment


              • #8
                Problem Solved with Workaround. Invalid SHA Returned from CNP.

                There is a problem. It has to do with Click and Pledge's Hash Implementation. Sometimes, it omits one 0 at random and leaves it as a blank, making it a 39 character string instead of 40.

                This is possibly due to a coding bug as referenced here on msdn

                I created a workaround for this issue, by finding and replacing each generated hash's 0's with blank spaces, creating an array of possible hashes and then checking the base64_decoded hash from CNP against the array of possibilities.

                It's dirty but it works. There was no pattern I could find as to WHEN a 0 would go missing, but from what I have seen it only loses one 0. I assumed at first it was the last 0, but that was not the case.

                Code:
                <?php
                function checkHashString($secret_key, $order_number, $amount, $receivedHash, $dump = false){
                    $hash = base64_decode($receivedHash);
                    echo strlen($hash);
                    $sha = sha1(utf8_encode("[" . $secret_key . "][" . $order_number . "][" . $amount . "]"));
                    $hashes = array($sha);
                    $i = 0;
                    while(strpos($sha, '0', $i) !== false ):
                        $pos = strpos($sha, '0', $i);
                        $hashes[] = substr_replace($sha, '', $pos, 1);
                        $i = $pos + 1;
                        echo $i;
                    endwhile;
                    if($dump):
                        $dump = $hashes;
                        $dump[] = $hash;
                        echo '<pre>';
                        print_r($dump);
                        echo '</pre>';
                    endif;
                    return in_array($hash, $hashes);
                }
                ?>
                You can test with the following data:

                Code:
                <?php
                    $results[] = checkHashString('letshashitout', 1406301520403881111, '50.00', 'MTkxOWJkMjU5YjIyODJiNTEyYTc1YTcxNzcxMmM2MTFhNGE0ZGEx');
                    $results[] = checkHashString('test123', 1404211124504441111, '17.00', 'ZTdhYjcwMjRiOWRlYzMxNThhNjdmOTc5ZDVmMTY5OTA5YWUyYTFk');
                    $results[] = checkHashString('test123', 1404181859539791111, '65.00', 'NjNiZDNiNTc5OTI2NmU2NjVmNmJjZmQ0Yjk2Y2FjMzJiY2I5MWI5');
                    $results[] = checkHashString('test123', 1404211146064211111, '897.00', 'NTQzNjdmODA1ZTJhN2QyOTg1MTgxNDE1NDM3YzdiZjFiNjNlY2FlOA==');
                    $results[] = checkHashString('letshashitout', 1406301520403881111, '50.00', 'MTkxOWJkMjU5YjIyODJiNTEyYTc1YTcxNzcxMmM2MTFhNGE0ZGEx==');
                    echo '<pre>';
                    print_r($results);
                    echo '</pre>';
                ?>
                It would be great if Click and Pledge could take a look at their algorithm. It is in fact returning less than 40 digit hashes after decoding. This means it is either a SHA error, a string building error or a base64 Encoding error on their side. I am leaning toward a encoding or string error.


                Originally posted by Simon View Post
                is something going on with the backend? The hashes that I'm getting back are matching only occasionally.
                The hashes being passed back from portal.clickandpledge.com don't always end in the == yet my calculated hashes always do.
                I've made a sample donation page here: https://kellpartners-sj--developer-e...nate?test=true

                and that posts to a super simple processor page. http://kellpartners.com/development/testHashCode2.php

                So far the passed hash code is has been valid ~15% of the time, and since my calculated hashes always look similar, yet the CP passed hash seems to be changing in length, I can only assume there's something going on in the backend that's calculating the CP hash? Because according the the SHA1 specification it always returns the same length hash.

                Comment

                Working...
                X