You’re right. This is one of the follow-ups that was not listed in the Next Steps section. Note that it won’t be the same set of Secrets - due to security reasons, we cannot let the experience private key to be available locally.
Yes, you can use Secrets within request headers. However, it’s not yet supported to use Secrets in the URL. We’re working on adding this capability, but there is a caveat that also applies for RequestAsync. Developers with write permissions can view server-side logs for HttpService, and these logs contain full URLs sent. Therefore my recommendation is to use Secrets in headers only, until we release URL filtering technique.
Are you running an instance in a local studio instance or in production? Secrets are only available for use in production and Team Create environments. If this is the case I recommend publishing your test place and trying it out on a live server. I also made a short script to specifically test out the problem you are having for use on a live server. Simply view the developer console in game to view its output.
local HttpService = game:GetService("HttpService")
local testKey = nil
local success, errorMessage = pcall(
function()
testKey = HttpService:GetSecret(SecretId)
end
)
if success then
print(testKey) --this will print Secret(SecretId) if successful--
else
warn(errorMessage)
end
Since they aren’t printable by design, is it meant for API keys only?
When this was announced at RDC23, I was thinking this could be a good way to store classic Twitter Codes if for whatever reason putting the plain text in server scripts would not be enough.
I believe this is solely usable for keys used in HttpService requests. It would be really cool to have a way to store ANY codes/keys/etc. without having them be plaintext in scripts or hosted off-platform using some API.
Real quick: I just did a simple boolean comparison test to see if you could compare the value of a Secret with plaintext, even though it wasn’t part of the described features. Expectedly, it didn’t work as the value of the Secret will always be Secret(SecretID) until its decrypted by Roblox’s server’s for use in a HttpService request.
Do you run “Team Test” or just “Local Test”?
At the moment, only Team Test and production can fetch secrets from the Secret Store. This limitation is done to protect your secrets from being downloaded to your local computer. We are working on supporting locally defined secrets (my thinking, when we run the Local Test in Studio, we should just read secrets from some local file on your computer).
This is a great feature! Is this heading torwards being able to send requests to roblox to get stuff like how many players are in a place/experience, or seeing how many visits a place/experience has?
I’m getting this error constantly during live servers, not sure what I’m doing as the key parameter in my GetSecret request is perfectly aligned with what I’ve set on the creator dashboard.
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.
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.
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).
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.
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.
