@mpociot @freekmurze I would like to have your opinion.

To correctly validate the signature we cannot have appId, appKey & channelName in the query params, but I'm not seeing any way to have them being recognized as actual route params because Ratchet is not very flexible on how the route is matched and what happens after.

So to fix any extra parameter added to the request being ignored en thus rendering the signature invalid too I added those to a blacklist to be able to reconstruct the signature how it should be with params that are not route params.

However this feels a bit dirty... we could also special case filter_by_prefix since it's the only actual query param that is being used in the entire (tiny) REST api. However would be cool if we can build upon the Pusher compat with some extra endpoints possibly that will make it more flexible doing it the way it's now...

Let me know what you think on what route (heh, no pun intended) to take with this.

Rebased with master to fix conflicts.

@stayallive You mention "After more testing this is broken since the route parameters are added as query params causing it to mess up the signature creation..."
So..is this broken?

Please read my update: #38 (comment)

It now works great, but not sure if there is a better way I'm missing.

This still feels a bit wrong to me to whitelist/blacklist the query parameter names but I can see no way to (without rewriting the router and possibly things in Ratchet) to know which query params are coming from the route parameters and which come from the user.

@mpociot can you let me know what you plan is with this? 😄

Want to know if I need to merge 1.0.3 in my fork or if I can fix something to get this moving forward.

@mpociot can you let me know what you plan is with this? 😄