Good Morning,
Currently, I have javascript code that listens to donations through PubSub and sends any donation info to a backend server. What is sent to the server is the exact PubSub Message received on the client side. Since the javascript code on the client side can be simply edited, I want the backend server to make sure the info it received is not just fabricated.
How can I do that??
Twitch doesn’t have donations. Streamers use other services like streamlabs for those.
What is the client doing with it that it needs validating? If the client only receives the data from a server it trusts and does not pass it on to anyone else, does it matter if the client modifies it for its own use, even if not originally intended by you?
If I leave the code the way it is right now, it’s gonna work flawlessly. However, my concern is a security concern. What if someone edits the javascript or creates a new application which keeps telling the server that XYZ donated 1000 bits to ABC’s channel?? The server’s database is going to be filled with fake information, which is… definitely not what I want. I want the server to be able to verify each donation message received from any client. Possible solutions:
I couldn’t find a real way of doing it, though…
What about instead of storing the data under their username or twitch ID, assign them a randomly generated userid. Then you have the javascript send the bits information with the userid. If the received userid doesn’t exist in your system, you know it’s fake. No one should know another person’s userid.
I got a “ProcessBits()” function that processes any Bit event from PubSub. What if someone edits the javascript code to make it get called frequently (e.g. each second)? This is going to send the correct the UserID and the fake information.
I wouldn’t use the frontend to host the PubSub if possible. (For use in this way) Going between your backend and a service describes man-in-the-middle attacks.
I thought that would be a way of doing it, but…
- Clients can currently listen on up to 50 topics per connection. Attempting to listen on any more topics will result in an error message.
- We recommend that a single client IP address establishes no more than 10 instantaneous connections.
The PubSub documentation did let me down…
Bits are not donations. Bits is not a currency. You can’t donate animated emotes.
Why is the client telling the server what happens? Why not have the server listen to pubsub and have the server tell the client what happens? No need to trust the client.
Why not have the server listen to pubsub and have the server tell the client what happens?
Three Reasons:
Because I cannot subscribe to more than 50 events through PubSub using only one one connection.
Because it is recommended that a single IP Address subscribes to no more than 10 events.
Making the server do that may require high processing power, which may force me to pay for a fairly expensive Virtual Machine rather than using a normal Web Hosting service.
Do you need to listen to more than 500 topics though? The 50 topics per connection is a hard limit as more than that results in an error message, but the 10 connections per IP is a recommendation and as the documentation says The two limits above are likely to be relaxed for approved third-party applications, as we start to better understand third-party requirements. so there might be options to go beyond that without issue.
As for 3. the additional processing power required to have the connections server side rather than client side will be minimal and not something that should make any difference. You also have to consider you are already listening for messages about cheers, except right now you’re just listening to the clients (and thus having the issue of not being able to ensure authenticity of the messages as having been from Twitch and not edited/made up) instead of listening directly to pubsub.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.