So I’m guessing that I would have to JSONDecode it then? Which means i’d have to add logic to the Subscribed message checking to see if the data is a string then decode it. :\
1 Like
The actual message requires to be a JSON encoded string. In your case, it would look something like
--data-raw '{"message":"{\"a\":\"This gets a 400\"}}"}'
Ah, I didn’t realize it had to be string because it also accepts numbers and bools, but looking closer it seems like those get converted to strings before actually reaching the game server.
I would suggest putting that somewhere prominent in the documentation. I expected this to follow the ‘normal’ rules about what can be serialized for DataStores, RemoteEvents, etc and I’m surprised to see this has different restrictions.
2 Likes
If you are sending a simple string, you don’t need to have decode logic on the subscriber.
For example, if you are sending a simple string as:
--data-raw '{"message":"message to publish"}'
Subscriber will only receive "message to publish"
The body data must be stringified JSON
Is there any way to confirm if a server has received a request using this?
As far as I can see the best way would be for the game server to send a http request telling your external system the message was received if you need this confirmation.
You’re just gonna have to believe it.
This seems like a sponsored ad lol…
2 Likes
I love this new feature! One thing I’d love to see would be the ability to publish a place to another place and then shutdown the servers of said place as well as the ability to update packages in a place.
Our update workflow relies on separate testing places which are essentially copies of their live counterparts and it is such a pain to open 5 different places, update all the packages in those places, publish them and then publish them again to the live counterparts.
Thanks for this!
Our service can now no longer have to manage painful user API keys and can just directly interact with Roblox’s API for some of my features.
Unfortunately, some of the features that we plan to provide need to be permanent so the DataStore API or internal requests to our API/database might be a better fit for the majority of our planned features.
Still, kudos!
It isn’t as insecure as you might think, the endpoint would still have to be authenticated against. Websockets work by making an initial http request to the endpoint, the server then upgrades the request into a websocket at which point a two way connection will be initialized. All this traffic will then be sent back and forth over a secure channel without much way to intercept it.
So it’s not possible for random people to listen into your MessagingService for your game (unless your API key is exposed)
This is the point you can now receive messages from external servers in the same way you would do with a normal MessagingService system among roblox servers
You need to read more carefully. He’s asking if external servers can receive a subscribing api point in the same way games can.
I should mention that my comment on websockets is Roblox’s stance, not my own: Web Sockets for servers - #5 by Silent137
This is Roblox’s stance on web-sockets for Roblox game servers, they likely have a different stance for allowing them through open cloud.
In both cases (game servers and open cloud), it would be originating from Roblox’s servers. The security risk in both are nearly if not completely identical. I don’t see how their stance would change.
Would be nice though.
Everything is TCP, HTTP underwater are TCP connections. The security risk for HTTP and TCP both are identical. Websockets over TLS still receive the same encryption that you’d get with HTTP requests so the security risks are all but mitigated.
However despite that I actually don’t think Websockets are useful for this, we already have an API to send in requests to the MessagingService, so having a Websocket (which is 2-way) is partially not usable.
A better alternative for listening to incoming requests could be a notification endpoint (something like webhooks), however instead of configuring them from inside the website you instead would create a notification endpoint by making a HTTP request to the API, providing the URL.
Roblox would then send a HTTP request to the provided URL to verify that the URL would be able to accept incoming requests, and Roblox would then proceed to send event of the requested topics the provided URL.
You could also have it so that the notification URL requires a daily refresh HTTP call, if not sent the notification URL will simply vanish from Roblox their side and not be called anymore, requiring a new one to be made.
A reason for this could be so that Roblox wouldn’t have to unnecessarily send notifications to provided URL if the service stops working, saving resources on Roblox their end.
Similar to how the Microsoft Graph Change Notifications API works.
Why don’t you just say that you’re the developer behind this… two new accounts its very obvious.
THANK YOU so much! Now i can do a livetime global message through a discord bot.
Is there a tutorial for discord bots to use this?