Bump, really need this
What’s your use case? It’s unlikely that this will be implemented if you don’t explain when this would be useful. You can already do this for your own modules using LoadAssetVersion. Using modules required by AssetId made by someone else is an attack vector against your game and you shouldn’t do it, my personal opinion is that we shouldn’t add any more features to support this.
Things like auto updating admin commands, etc
The current way with insertservice requires the asset be owned and requires it be inserted, moved out of the model that its inserted in and then required
This does not seem like a good use case to me, you should not allow any code run in your game unless you have wrote the code yourself or audited the code to make sure it’s ok. Using auto updating admin commands is insane, even if the creator of the commands is not malicious their account can be compromised or they can make an update that conflicts with the existing code in your game and cause bugs.
With the new chat we increased the maximum amount of characters a player could chat from 140 to 200 characters. In a popular admin command script there was a check if a message from a player contained more than 160 characters, if it did it kicked the player from the game. This command script was being used in at least one front page game. You shouldn’t put thousands of lines of code you haven’t read into your game, it’s even worse if it is auto updating.
I think we should probably break require for assetIds the creator doesn’t own, it’s too much of an attack vector against games that use it.
2 Likes
I agree that the person should have to own it, however if that’s implemented I see no reason not to allow us to require the latest version directly as we can already do it with insertservice?
This would ruin require() in script builders, as the owner of the script builder would have to own the module and I prefer my script builder modules closed-source.
If you’re going to implement this change, please add a game configuration option to allow unowned modules.
3 Likes
I have to admit that I like the fact you can use require( ) in any game however it opens up MASSIVE security risks for even FE games which is not good. It basically entirely circumvents the restrictions put on the InsertService…
It’s not really a good idea to invite people to shoot themselves in the foot in order to support such a niche case, so I can’t really agree with this proposal.
4 Likes
Everyone is overexaggerating the dangers of require, there is no way for an exploiter to use require() as it can only be used serverside. Enabling it for unowned modules would not be shooting yourself in the foot.
2 Likes
A random exploiter coming into your game and requiring a module isn’t really the concern here. There have been cases in the past where a private module was used in many games and was maliciously edited by its owner. Running code you can’t see in your game has never been a good idea.
I think the concern isn’t that exploiters will take advantage of them, but as @TheGamer101 mentioned even a trustworthy person could have their account compromised and your game could be next on the list since that person has server script privileges to your game through the module.
That being said, I rarely see private modules being used for features the creator could just as easily create. If it’s an option between having a game that’s vulnerable and not having a feature that’s likely critical to the success of the game, I’m sure most sensible people would choose the former. It sucks that they don’t have access to the source code, but they’re taking what they can get.
I don’t agree with how bad this is considering I’m typing this on a closed-source auto-updating Windows 10 machine which could receive bad updates due to a compromise in Microsoft’s security. It all comes down to whether or not there is enough demand for the feature, but so far there doesn’t seem to be much.
2 Likes
I use it alot in script builders, and I know there’s other people who do.
The admin scripts being used across thousands of games have their source loaded by require().
But do any of them actually need to auto-update while the game is running?
You’re right, there are other people who use it in script builders. There are also immeasurably more people that this wouldn’t benefit at all, so even if you can make a strong enough case for the feature, it’ll never be high enough of a priority that ROBLOX would implement something just for script builders. Loadstring was disabled, even though it was used in script builders, for instance.
No, the latest version is loaded upon the server starting, and some admin scripts are closed-source.
Disabled, it’s still usable if toggled in ServerScriptService and after closing a pop-up warning. I’m hoping the same can be done in this case.
That setting is for clientside loadstring – serverside loadstring is completely gone.
So then they have no use for busting the cache on require
I think they want to have it auto-updating, but can’t because of the cache.
And that setting is for serverside loadstring, not clientside.
For the whole “private modules aren’t secure” discussion:
Admin scripts would go back to the old days of using LoadAsset to auto-update. It’ll affect less people, as the model has to be taken, but still. If you care about your game being 100% secure, just don’t use private modules. Otherwise, do what you want.
On-topic:
I’m more worried about what require() will do/return when it loads a module for the second time. Will the first “runtime” be terminated? Or is it like “Reload script” in studio that just clears the cache value and re-requires it (but the new version this time)? I’m not entirely sure if I’ll use this (but auto-updating certain modules sounds fun), but might be handy.
ROBLOX actually has a built-in update mechanism for modulescripts that return tables. If you have a modulescript that returns a table and you reload it in studio, the old table is cleared and filled with the key/value-pairs of the new table. In that case, having local idk = require(...) and using idk.whatever() would automatically use the new method. again: this is already happening in studio, not an addition to this feature I’m inventing
It wouldn’t affect previously required objects, it’d just be a way to require the latest version.
Exactly. The whole “two versions running at once” might be a problem if your module starts threads and connects events etc.
Well, the same would happen if you just insert the latest version and require it that way. Seems like a non-issue, if they’re using this without cache they should handle cleaning up the old module.