feat: remove API secret in favor of explicitly passing user HMAC #31
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note
This PR supersedes #32
In this PR
This changes the way the Swift SDK handles user HMACs. Previously it was expected to pass the API secret so the client side SDK would calculate the HMAC. This is a bad practice and discouraged.
With this change the SDK only allows for a
enableHMAC
toggle, and an optionalhmac
parameter to theconnectUser
call.Test Plan
I've tested the change in the Example app by using the API key from a project with Security enabled.
I've also extended the Example app so that one can provide an hmac when changing to a different user.
I could confirm that notifications did load when providing a correct hmac, while they returned console errors when no hmac was provided (added line breaks for readability):
When providing an invalid hmac the following error was provided (added line breaks for readability):
Open questions:
Is theResolved in ba8e20denableHMAC
flag onMagicBellClient
actually needed? It could be deferred by whether an hmac is passed intoconnectUser
. Also the truth whether hmac is enabled resides on the Magicbell project configuration on the server.