You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure if this is a bug in ably-php, ably-js, or somewhere inbetween. Can't really see how it could be any of them, to be honest, there doesn't seem room for anything to go wrong in any of the stages that I can see. But it must be going wrong somewhere.
By the time it gets to ably-js, it looks like: {"ttl":null,"capability":"{\"redacted:*\":[\"subscribe\",\"history\"]}","clientId":"customer-38","timestamp":"1500420264269","keyName":"<redacted>","nonce":"6b8c0f7b37bf2d100fa210204f8d80ad","mac":"oAsynffIX9glVWpJcmNlDpgvZx9dMCNF3dctiLk1VGM="}
With the ttl being null. This results in the mac being incorrect, as the ttl was 86400000 at the time the mac was signed -- which I've confirmed by getting the mac to match if I force it to be that manually.
Reply from customer about how he's serializing the token request:
I use symfony so it uses the JMSSerializer Bundle to serialize the json. I created a custom entity as JMSSerializer converts camelCase to underscore case by default so I needed to use a custom entity so that this would not happen
Will follow up on whether it's possible that that might remove the ttl
https://app.intercom.io/a/apps/ua39m1ld/respond/inbox/all/conversations/10861930672
Not sure if this is a bug in ably-php, ably-js, or somewhere inbetween. Can't really see how it could be any of them, to be honest, there doesn't seem room for anything to go wrong in any of the stages that I can see. But it must be going wrong somewhere.
Customer creating token request in php with
By the time it gets to ably-js, it looks like:
{"ttl":null,"capability":"{\"redacted:*\":[\"subscribe\",\"history\"]}","clientId":"customer-38","timestamp":"1500420264269","keyName":"<redacted>","nonce":"6b8c0f7b37bf2d100fa210204f8d80ad","mac":"oAsynffIX9glVWpJcmNlDpgvZx9dMCNF3dctiLk1VGM="}
With the ttl being null. This results in the mac being incorrect, as the ttl was 86400000 at the time the mac was signed -- which I've confirmed by getting the mac to match if I force it to be that manually.
┆Issue is synchronized with this Jira Bug by Unito
The text was updated successfully, but these errors were encountered: