AddPrefix is not working in production! (addPrefix is)
8 Likes
Yeah, sorry, that legacy affordance only works for Instances, not atomic data types so it doesn’t actually cover this case, it’s just wrong as is. They were not intended to be camelCase, this will be fixed (don’t worry if you’re already using it, we won’t break the camelCase one).
7 Likes
I will begin work on converting both of my modules to use Secrets now that it’s available to me. Thanks for all of your work on this, developers!
(One of the milestones for GuildedRadio v1.0 getting released was this reaching release status.)
5 Likes
Amazing, a big step in the right direction for securing the communication between Roblox games and third party backend applications
7 Likes
I see most plugins use an API provided by AI services (obviously having to reveal their key). Could there possibly be an implementation of Secrets in plugins?
7 Likes
Nice update! But why the secret wouldn’t be able in the body of the post request? Using a glitch.com code hoster I can’t send the secret to compare it with the one in the .env file so, at least for me, this update was a bit useless…
6 Likes
Plugins run on your computer (client) directly so the computer needs to know the api key. The plugin author could set up a proxy (request forwarder) for it tho and add the key there instead of giving it to the client. They can also implement limits there. I don’t see Roblox proxying requests just for secrets to work in plugins.
Normal:
Client → (Prompt and key) Ai Service
Proxy:
Client → (Prompt) Proxy → (Adds Key) Ai Service
Hope this helps! If not feel free to ask questions.
5 Likes
Are you sure that you can’t access request headers?
Also authorization in request header is pretty standard, look at the discord api and opencloud api.
6 Likes
Are secrets encrypted at rest and when the game server fetches them?
Also is it possible in the future for us to pass in our own encryption key/passphrase to permutate it during runtime (Like a simple AES-256 pass) to minimize collateral if this service ever gets compromised?
6 Likes
Studio still requires an internet connection to function. Because scripts are allowed to send HTTP requests, I don’t think it would be a bad idea to bind Secrets to the User (in this case, the plugin author). Not everyone has the resources to set up a proxy. Just the easy way, you know.
6 Likes
If the computer of the users don’t have access to the key they can’t make the requests to the ai, which means no responses, which means the plugin is broken.
You can’t lock it to the author, as they are not the ones making the requests.
The requests of plugins do not run on Roblox servers like the requests in normal script in a normal game server. The requests made by plugins are sent by your computer directly. You would be able to trigger discord webhooks for example, as your ip is shown, not a Roblox ip. The same happens if you play your game in studio, without using team test.
5 Likes
After this update, the error message ‘The current thread cannot access ‘Instance’ (lacking capability Plugin)’ has been consistently appearing in the output. This issue occurs exclusively when the part’s parent is a mesh part.
6 Likes
Cooking! No longer will I have to worry about screenshares, awesome update!
5 Likes
Wonderful feature; I have been waiting a long time for it to arrive.
6 Likes
This is my fault, - fix is on the way! AddPrefix will also work after the fix is deployed.
We studied existing APIs, and could not find a case where the Secret is expected to be a part of the request body. Should this case arise, I think, it won’t be hard to support it.
Yes. They are end-to-end encrypted: your browser first fetches your experience public key, encrypts the secret (using libsodium Sealed Box), and then sends it to Roblox. It is stored exactly as received, and is only decrypted when the game server starts.
Not sure if I understand. Which service can get compromised? And how can the collateral be minimized? As one of the future goals, I can imagine extending Secret type to enable generic crypto. Say, for storing encrypted values in Datastores, and then using the Secret to decrypt. That, however, raises moderation challenges to the next level.
Plugins are running on your local machine, which does not have access to the experience private key. Therefore, it is unable to decrypt secrets.
It is expected to be reliable: secrets are retrieved while the game server starts. GetSecret method is synchronous, it does not make any remote calls. It is still possible, although unlikely, that Secret Store is completely down, while everything else is up. In that case Can't find secret with given key exception is thrown. Game server will keep retrying to fetch secrets, until it succeeds.
9 Likes
By this you mean the method call will throw an error in the calling thread, and in the background the game will keep retrying until it gets it? So the correct usage code might look something like:
local secret
local success = false
while not success do
success, secret = pcall(HttpService.GetSecret, HttpService, "key")
task.wait()
end
8 Likes
Woo woooo, thank you for this!
6 Likes
Very nice addition!
It would be nice if the error message for using it on local servers wasn’t Can't find secret with given key, as this is quite misleading
It would be great if there was a way to add the secret to studio somewhere, so when running locally, it would get the secret from the local computer, allowing for Secrets to be used on local servers, while keeping it hidden to other users, if you happen to enable team create later on or something, or have it on but want to run it locally anyway
12 Likes
Let the chaos ensue, break the camelCase!
4 Likes
This is a valuable feature that has been a long time coming, thank you!
However, it’s missing a critical feature.
There NEEDS to be some form of local env secrets.
Being unable to use Play Solo for any experience that utilizes Secrets is such a huge workflow killer that I cannot adopt this feature. Making my game only function in Team Test is simply not an acceptable tradeoff. The blow to development velocity is huge. Developers can technically implement something like this themselves (assuming they use fully managed Rojo) but A. not everyone uses Rojo and B. if everyone is writing the same exact code, it’s something Roblox should have provided.
Edit: I’ve literally gone back to storing keys in plaintext because adopting Secrets makes it impossible to get anything done.
30 Likes