Won’t affect studio plugins - everything from Studio is authenticated traffic.
In that case, I am not going to worry about it since I don’t do anything in Roblox unauthenticated.
This will break my fairly popular experience: Studio Lite - Roblox . It allows player to build, script and publish games to their own profiles. Studio Lite’s Toolbox has a model insert feature that allows players to import models from the Roblox store into their own games, just like Roblox Studio. That feature needs the assetdelivery endpoint since InsertService:LoadAsset requires the asset to be in the experience creator’s inventory (my inventory), and there is no way for me to programmatically add assets to my inventory.
I suspect that just adding my own authentication API key will not solve the problem, since I need to retrieve assets that are not in my inventory. The real Roblox Studio is freely available for anyone to download assets that are not in their inventory, so why shouldn’t an experience have the same capability. I find it odd that we have to go through a proxy just to get an asset that is easily retrieved in Roblox Studio. And now the assetdeliver via proxy capability is being removed.
The best solution would be to give trusted, verified developers access to an unlocked version of InsertService:LoadAsset so we can retrieve asset just like Roblox Studio does, without a proxy, and without inventory requirements.
The worst solution (but the only solution I see right now): I will have to train players to add store assets to their inventory, and create an open cloud api key to their inventory, then I will prompt them for it so they can import the asset into Studio Lite. This is not a simple task and will take much more than one week. Please see the best solution above.
EDIT: Ok, I panicked. Publicly available assets are still accessible. Since I am using an external proxy, I just need to pass it a new cloud endpoint with an API key scope “legacy-asset:manage”, which returns a temporary location url, that I can then use to get the asset. The timeline is very short.
5 Likes
I’m not liking this at all… 
as I develop with web APIs a lotttt! like extensions, plugins and I create so many API based games, already a problem that I have to always proxy for games and a lot of APIs that don’t work that way and the rate limits really not great…
4 Likes
The staff guy said it only affects out of experience api calls, you’ll be fine. As for the purpose of the update, asset security
i dont understand this, what exactly he is saying
Are you using an external server to parse the binary data? If so, how do you send it back to the game server? Do you use rbxdom to parse it, then converting it into an intermediary format?
Or are you using wasynth and compiling rbxdom to wasm, then compiling the wasm to Luau and using it in your game?
1 Like
I use the assetdelivery API (assetdelivery.roblox.com/v1/asset/) to download RBXMs locally without needing to drop it into studio first.
Are there any changes I need to make to what I use for this.
1 Like
I hope it doesn’t mess anything up, when you upload public assets (intentionally changing settings so that it’s available to the public, sharing the asset) it should work and be available for everyone, at least I hope…
1 Like
this utterly nukes the quality of the image and is not a viable solution
You should be using game:GetObjects for this since its looser in its restrictions. Please do not use LoadAsset in plugins, its horrible.
Is there plans for a open cloud alternative for the batch endpoint?
We have functionality that fetches numerous assets at once and I’d imagine we’d quickly hit rate limits calling the new endpoint for each individual one.
2 Likes
Can’t they just do the blocked operation in a published experience, and download the asset using an exploiting client?
That’s my immediate thought of a simple bypass.
You’ve probably accounted for that is my guess…
I tested, and as long as your are logged in the browser (aka having a User Cookie on your browser), you can use the classic endpoints.
Are public assets such as decals, accessories and the like going to need authentication?
Yes. Even “public” assets will require an authenticated request. This change won’t break any experiences as all gameplay and studio usage is done while authenticated. This will mainly affect creators making calls to asset delivery outside of experiences (for example: from a browser extension, or through a proxy)
Is there a way to even test this?
We’re monitoring all unauthenticated requests right now. If you have any questions about a specific place or asset we can check if it’s in our list and let you know.
And one week is way too short. It should’ve been 2 weeks.
We hear you. We try our best to give our creators ample time to make changes, but some changes must be implemented quickly for security. That said, this feedback is being shared with the team. We appreciate your understanding.
1 Like
We’re targeting 3PM PST - we’ll post if there are any updates
1 Like
My main concern here is user-facing third-party tools and rate-limits. Requiring a user to enter their cookie for a service would be absolutely horrific for security and the alternative of requesting an API key / oauth token is not only also inconvenient, but it still also requires the user to have a Roblox account (which mightn’t be the case for third-party websites, plus the fact that some accounts may be <13 and unable to authenticate via oauth to view public assets). This also makes the assumption that the user would be willing to give what could presumably become full asset management permissions on their account to us, aswell as presumably gaining access to any private assets they may have on their account. 
All the legacy OpenCloud APIs have taken too broad of a view on scopes. Rather than separating read and write permissions, both have become essentially the same scope. This has led to significant difficulties with designing my application to only use the scopes it needs, I essentially am forced to ask for way too much permission for lack of an alternative. For example, I recently wanted to use oauth to list whether someone has game edit access; I was turned off the idea once I found out that the scope for doing so was also shared by the endpoint for making experiences public/private, something my application does not need and a hefty permission for any developer to consider giving a third-party website.
Using a backend for the requests isn’t really an option either, because I can only assume API keys have extra rate limits. Per-account cookie rate limits would presumably require us to scale in multiple alt accounts as our service grows to handle more traffic, not a very scalable solution. API keys also aren’t exactly ideal since they can’t scale like our services can, and managing the distribution across multiple keys / accounts is a significantly complex task. A lot of developers are already required to rotate IPs for bigger services, and rotating accounts / keys is another unfortunate roadblock.
I understand that this was presumably done to prevent scraping, but the alternatives don’t match the needs of third-party tools just yet. I’m not even sure if there is a perfect solution here, and to clarify, I mean no offence to the team in this. I just thought I’d raise my personal concerns here, just in case others share the sentiment.
2 Likes
This API is core to my workflow when working on big projects where you don’t always know where an asset comes from. It’s nice to be able to, for example, download an image an artist who left the company made, desaturate it, then re-upload it as a white image that can be recolored in engine.
Adding an authentication requirement will complicate some memory usage auditing tools I have in place.
Realistically this change is fine in the long run, it would just be nice if Roblox provided official tools for downloading assets in a game, rather than making the developers do this ourselves. It would likely take me a good few days to do a project like this, and in my free time when i am working on Roblox games full time.
1 Like
Go back and read what I wrote… I am using LoadAsset from the command line. I do not write plugins.
1 Like
As long you are logged in on the browser will you still be able to use asset delivery via URL in that browser? Also, will browser extensions such as BTRoblox will still work as long as you are logged in? (As it uses a asset delivery URL to download assets, and if a user cookie is valid, then it should work, right?) Also this doesn’t help secure creator content that well, as people can just insert service a hat for example and then download the obj, meaning UGC stealing will still be prevelant (unless you guys actually do something about that). And if you can still do it in a browser with a User Cookie, you can grab audios and decals that way. What is this protecting creator content from, exactly?
1 Like