Thank you for noticing! It could’ve been caused by the oversight on our side, which, I believe, has been now addresses. Apologies for the inconvenience - Secrets, indeed, are expected to be readily available straight away after launching the server.
2 Likes
Hi,
There’s a paradox with requiring that Studio be in Team Test in order to use Secrets, and this paradox defeats a lot purpose that Secrets have. It makes it impossible to do any debugging/development of a system without analogously “pushing to main” every time you use it.
tl;dr - I think RunService needs something like IsTeamTest(), but here’s how this is problematic:
-
I have a webserver that should only do work if an incoming request has passed an accepted Secret in it’s headers. Creating an inclusion list for all of Roblox’s IP ranges simply isn’t going to cut it.
-
This webserver should not touch sensitive systems (Open Cloud DataStores, MemoryStores, MessagingService) if this secret denotes that it came from a Studio-based environment so that we may debug the game, systems, et cetera.
-
The Team Test environment does not consider itself “in Studio”, so developers have no way of safe-guarding external systems from a Team Test session.
The alternative is to just simply pass a hard-coded studio header, but now my webserver is vulnerable to doing unauthenticated work because the secret is stored in plaintext to anyone with access to the code, and also isn’t secret anymore.
The need to know if we’re in a Team Test session is valuable, so that we can use a Studio/Team Test specific Secret.
2 Likes
The best solution to this problem is querying and whitelisting the server and port that your Team Test is running on. Of course to be completely secure you’d need to prevent IP spoofing, but that is probably overkill for your project.
Check out the GameJoin Api v1, specifically the portions regarding team create sessions. You are going to need a CSRF token to access these endpoints, which you can get by sending a request authenticated with your .ROBLOSECURITY code to the logout endpoint. This request will return using the IP and port your Team Create session is running on so you can just whitelist that instead of everything.
I know this solution isn’t ideal, but the only other way to seemingly solve this issue would be for Roblox to add specific TLS/SSL certificates to requests that have been sent via local studio, Team Create, and live game instances to differentiate. Maybe they have something in the works like that, but that just seems like a big headache to me lol.
2 Likes
No. They just need to add an IsTeamCrate() in RunService so that we can differentiate. This should have nothing to do with certificates, whitelisting IPs, or pinging any specific endpoint.
1 Like
I understand what you are saying, and I provided a working solution for your problem.
That being said an IsTeamTest() function for RunService simply wouldn’t be secure to send requests to your webserver. You would just be able to run the body inside of the conditional without that check. This is where certificates come in. If your request is signed showing that it is from a TeamCreate session you would be able to properly handle and serve that request with what you want, rather than what you would send for a request via a live game instance.
I think an IsTeamTest() function could work quite well for adding tools and functionality for testers directly in app, but this would not be a secure way to verify that a specific request is coming from a TeamTest session on your external server.
I’m happy to provide any clarification you may need and please don’t take this criticism too harshly.
If you really need a feature like this you could simply check using IsStudio() and checking the playercount
Hang tight, we’re working on a solution that will be local to the Studio instance, and are used for locally running games!
5 Likes
Myself and I’m sure many other developers would looooooooove to use Secrets as soon as this update is released to it. It’s the only thing holding us back right now. 
1 Like
Hey can we get manage secrets as a separate permission instead of only group owners managing them? It isn’t so convenient to contact the group owner every time we want to add a secret.
2 Likes
Separate permission has not been implemented yet, but we’re working on it!
3 Likes
And here you go! Roblox Studio lets you configure secrets locally. Go to File → Game Settings → Security, and when “Allow HTTP Request” is enabled, a new text box appears, allowing to enter locally-defined Secrets in JSON form. Example:
{"google": ["cGFzc3dvcmQ=", "*.google.com"]}
It’s on me to document it better, but I believe it’s so exciting that I can’t wait to share it!
Other fixes and improvements are coming soon!
6 Likes
This is a really excellent feature, and I have been looking forward to something like this for quite some time.
However, as the Web Developer for our Group it’s dissapointing to see that only Group Owners can edit Secrets, this is drastic for my Workflow, as the Owner of our Group is in a different Timezone and not always available!! Would’ve been so much nicer for anybody with Development Permissions in a Group to edit Secrets!
2 Likes
Yet another updated landed - it is now possible to use GetAsync and PostAsync. Stay tuned for more!
2 Likes
Hi,
I’ve just tried using this now and it doesn’t seem to be working.
Using the code print(game:GetService("HttpService"):RequestAsync({Method = "GET", Url = "https://apis.roman-dev.com/leaderboards", Headers = {auth = game.HttpService:GetSecret("test")}})) is printing “Can’t find secret with given key”, and the secret is also correctly configured on the Creator Hub. I’m testing in a Solo Playtest.
My “Secrets” section in the Security tab of Roblox Studio settings is as so:
{"test": ["SECRET", "*.roman-dev.com"]}
Also, I’ve noticed whatever secrets you put in there delete once you close Roblox Studio. Could this be fixed so they persist during sessions?
1 Like
Skip to the end for a quick fix for your Creator Hub made secrets
Can confirm that locally configured secrets inside studio do not work as implemented. Tested using the example provided by zipcatmax and your own using a pcall and yielding.
I tested this using a local studio, a team build test session, and a live production server, none of which worked returning Can't find secret with given key.
I can also confirm that secrets configured in this way do not persist between studio sessions in the game settings menu.
For Secrets created and configured on the Creator Hub you need to be testing them in a team build test session or a live production environment. These are not yet functional in local studio instances, but zipcatmax is working on that.
1 Like
Thanks a lot for confirming.
Should’ve said this earlier, but I am in fact aware of this and Creator Hub secrets are working as intended, my only issue was with the locally configured ones inside Studio. Thanks 
1 Like
This is a bug! I managed to reproduce it. My sincere apologies, let me take some time fixing.
2 Likes
Thanks! Please keep us updated.
it would be great if “Local Test” can fetch secrets from the Secret Store. I find it ridiculous that I have to go into Team Test every time I test my game. and it seems even more ridiculous to me to wrap it in pcall just so it doesn’t give an error in “Local Test”.
This is an update from a bit ago, although it’s not detailed whether locally configured secrets work in local testing enviroments or are just an option to configure secrets locally to work with live sessions. That being said, zipcatmax has said they are working on secrets for local instances:
That being said, AFAIK the current implementation of this is still bugged, but zipcatmax is working on a fix.
Unsure if you will be able to access the live secret store or only be able to use secrets setup locally/read from a local file.
The former could create some security vulnerabilities based on the method of implemention so it’d be interesting to see how it’d go. This is beyond the scope of your question, but I find these sorts of things very interesting!
2 Likes
We won’t be able to implement this in a secure way. As soon as the secret gets onto developer computer, there is no way for us to ensure it is not captured and saved somewhere.
I found and fixed the problem in Studio. Next release will have the fix.
2 Likes