I have a custom implementation of my connect back end app in Python. The app has been happily processing JWT tokenns with QSH claims for a couple years without incident. I patched my app for this fix by opting into context qsh claims.
My app only exposes webhooks and makes api calls. It does not have any front end components. Given this I was under the impression from the above threads that I would not need to make any change in the app.
I started seeing a small spike in qsh claims violations and that has continued to grow this morning, so I am now trying to figure out what I need to do with my custom implementations.
Assuming that somehow I also needed to accept a static qsh claim of the form ‘context-qsh’, I updated my qsh validation code to look like the following.
claims = jwt.decode(token, verify=False)
if claims['qsh'] != 'context-qsh' and claims['qsh'] != hash_url(http_method, url):
raise DecodeError('qsh does not match')
I am still seeing the DecodeErrors being raised, and it looking at the logs it looks like I am getting a qsh that is not a static qsh or a match to the url hash.
By rights I should reject this, but it also seems to be coming from a legit install of the app, so I am not sure what I need to do here.
The line of code after this is
and this seems to pass just fine, so its a token signed with the correct secret as far as I can tell.
Cant afford to throw away the valid calls from a client app, so for now I am thinking I will by pass qsh verification to keep the ship running.
Any advice is much appreciated. I am uncomfortable with accepting webhooks that fail qsh validation, but I don’t know what else to do.