Skip to content

Consistent encoding for shared secret #127

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 22, 2021

Conversation

callum-oakley
Copy link
Contributor

@callum-oakley callum-oakley commented Nov 2, 2020

This SDK disagrees with the shared secret that the other SDKs produce, because it encodes the master key to a latin1 string internally, and then concatenated with a utf8 string (the channel name) before being passed to the sha256 method which (probably) interprets strings as utf8. This is pretty insane, but it still "works" as long as you don't try to use two server libraries simultaneously, because then they will disagree about what the key should be.

Regardless, we should avoid all this encoding nonsense internally by just keeping everything in buffers once we've decoded from base64. After this change pusher-http-node agrees with the ruby and go SDKs at least. I'm going to check the others next.

edit: binary is a horribly confusing alias for latin1. yuck.

@elverkilde elverkilde merged commit 08ee090 into master Apr 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants