X-Hubspot-Signature python validation for Hubspot App
resolver
I haven't been able to work out how to recompute the X-Hubspot-Signature successfully at my server when a data fetch request is made for a CRM card set up on the app. I have confirmed that my code using the python hashlib as described in the documentation works with the provided examples:
When I use my app's client secret and build the string as described to produce the hexdigest, my computed value does not match the value provided in the X-Hubspot-Signature header. I checked to confirm that the protocol wasn't the issue as indicated in other posts (not http vs https).
The data fetch includes query params and a property that I configured for the card's target record type (Deals). I have tried both removing the query params and including them when computing, but still no luck.
dic 13, 201911:50 AM - editado dic 13, 201911:54 AM
Colaborador
X-Hubspot-Signature python validation for Hubspot App
resolver
Many thanks to @WendyGoh for helping me work towards a solution!
I may have missed this in the documentation, but Hubspot computes the signature BEFORE url-encoding the param values.
The reason that my signature computation was not correct was my handling of url-encoded parameters in the full request url hitting my server. There were a couple of specific details, though, that I was able to suss out.
One param hitting my server contained an email address. When taking the raw request to compute the signature, the '@' was still encoded as '%40'. The email address value had to be url-decoded prior to computing the signature.
The other param that was causing trouble was a bit thornier. We have a custom property that contains a url as the value, with query params on that url. For demonstration purposes, the param value is received in the raw request url param as something like:
Except this also fails the signature computation. The query params on this url property value need to remain url-encoded for the Hubspot signature computation to match. In the end this needed to be:
Once I updated my code to ensure the query params of the Hubspot request were properly url-encoded and url-decoded as described above, the signature computation worked as expected.
I'm printing out the Hubspot header vs my computed value to test my results. I've tried several variations on the url used, but haven't had any luck identifying the problem.
At a glance the code looks perfectly fine. In this case, let's try using the exact python code that HubSpot documentation here: Validating the v2 request signature, and see if it works?
I have run that code successfully, but I did still have to utf-8 encode the `source_string`. Here is my exact console output in my runtime env:
Python 3.7.4 (default, Sep 12 2019, 15:51:10)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> client_secret = 'yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy'
>>> http_method = 'GET'
>>> http_uri = 'https://www.example.com/webhook_uri'
>>> source_string = client_secret + http_method + http_uri
>>> source_string
'yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyyGEThttps://www.example.com/webhook_uri'
>>> hashlib.sha256(source_string).hexdigest()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: Unicode-objects must be encoded before hashing
>>> hashlib.sha256(source_string.encode('utf-8')).hexdigest()
'eee2dddcc73c94d699f5e395f4b9d454a069a6855fbfa152e91e88823087200e'
When I attempt to compute the signature on my server using my app secret and the documented fields, my hexdigest still does not match. Would it be helpful to take this offline so I can send along my app specifics?
dic 13, 201911:50 AM - editado dic 13, 201911:54 AM
Colaborador
X-Hubspot-Signature python validation for Hubspot App
resolver
Many thanks to @WendyGoh for helping me work towards a solution!
I may have missed this in the documentation, but Hubspot computes the signature BEFORE url-encoding the param values.
The reason that my signature computation was not correct was my handling of url-encoded parameters in the full request url hitting my server. There were a couple of specific details, though, that I was able to suss out.
One param hitting my server contained an email address. When taking the raw request to compute the signature, the '@' was still encoded as '%40'. The email address value had to be url-decoded prior to computing the signature.
The other param that was causing trouble was a bit thornier. We have a custom property that contains a url as the value, with query params on that url. For demonstration purposes, the param value is received in the raw request url param as something like:
Except this also fails the signature computation. The query params on this url property value need to remain url-encoded for the Hubspot signature computation to match. In the end this needed to be:
Once I updated my code to ensure the query params of the Hubspot request were properly url-encoded and url-decoded as described above, the signature computation worked as expected.
X-Hubspot-Signature python validation for Hubspot App
resolver
We began experiencing an issue with the X-Hubspot-Signature v2 validation earlier today beginning at 10am EST. Our computed signatures no longer match the signatures that we receive from Hubspot.
Seemed suspicious, but we haven't had any issues until this morning. Our implementation is the same as described in my post back on Dec 13, 2019. Did anything change today on the Hubspot side related to v2 signatures? Or perhaps treatment of URL params?
I have gone through a number of variations to attempt to reverse engineer our signature computation to match what we receive from Hubspot but have had no luck thus far.