Just done a little debugging, turns out that calling GetSecret as soon as the server initialises causes the Can't find secret with given key error.
Just added in a small yield before the request is sent and it seems to be working fine now.
1 Like
I experienced the same issue with GetSecret returning that the SecretKey did not exist, even though the key existed in the experience. I can confirm that yielding (Thanks for the suggestion) fixes the issue.
This is a bug and should be addressed - GetSecret is run synchronously, I expect it to yield until the secrets are retrieved from the secrets store and then check to see if the key exists; not (As a dev) needing to wait an arbitrary amount of time for new servers to spin up and hoping that the keys are retrieved in time.
1 Like
Current behaviour is a compromise: game server startup is not blocked by Secrets (primarily, because most servers do not require secrets available at startup). However it is expected that Secrets are fetched in parallel with the rest of game server startup, and by the time it starts, Secrets are available. That said, I also consider “Secret not exist” as a problem - either a bug, or rare unfortunate event that should be happening super-rarely. Based on your feedback, this isn’t rare at all, and therefore must be looked into. One approach that I think is useful would be exposing RefreshSecrets functionality, that is synchronous, and waits until Secrets are received.
3 Likes
Thanks for looking into this! For additional context, I was using the Knit framework by sleitnick, and the GetSecret call was in the KnitInit portion of a server-side service. Putting the GetSecret call under the KnitStart portion of the code fixed it (a few hundred milliseconds after a new server starts up).
1 Like
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