LittleBigRefresh
Add an "asset holding area" to allow server owners to require manual review for potentially unwanted assets
Motivation
As I mature my script tooling, ive wanted to figure out a way to allow hashed scripts with more fine grained control than currently provided (block all scripts, or block none).
This will allow safe scripts to be manually reviewed by server owners and allowed/disallowed if wanted. One example of a script someone may want to upload attached to a level is the set of LBAC scripts, some creators may want these scripts in their levels, and it would be nice to let server admins review these script files and allow them if wanted.
Overview
For uploading scripts (and other potentially unwanted things, like maybe models) to be safe, there needs to be a way for people to be able to upload an asset, and have said assets held in "review" (requiring a server admin to accept/deny said upload request).
When an asset is held in review, only the uploader is able to download said asset from ingame. Admins will be able to view all "held for review" assets and be able to download said assets through the API.
Once the admin has reviewed said asset, they will be able to send a request to the API to either allow, deny, or block said asset
If allowed, the asset is no longer held for review and all users are able to download it, if denied, the asset will be deleted from the server. If blocked, the asset will be deleted, and the hash will be blacklisted, preventing users from uploading that asset again. (once again, the API has an endpoint to list blocked hashes, and un-block a hash, if so desired)
The frontend could be modified to display previews of these asset types, whether it be converting an image to PNG to display in the browser, or disassembling the script and showing it to the admin, allowing them to read how it works, and see what it imports/exports.
Technical details
The refreshGameServer.json will have a new field added, being a "held assets" array, when an asset is set to be "held", this asset bypasses the mod filter, and even if the mod filter disallows this type of asset, it will still be uploaded to be held for review, this allows you to have very fine grained control over whats blocked outright and whats just held for review.
The array will store the names of the assets to be held, see this enum
The specifics of the API are best left to an implementation, so i wont try to define a strict API structure here, but it should have roughly these APIv3 endpoints
- list all held assets
- get asset info for specific held asset (normal endpoints do not work except for the uploader [even admins must use the held asset endpoints])
- download held asset
- set status of held asset (approve, deny, block)
In Refresh, we can implement this by introducing a new table based on a class HeldAsset
This will have two fields
status: HeldStatus (enum with `awaiting_review, blocked`)
hash: string
If an asset is awaiting review, its left in the table as awaiting_review status if the asset is approved or denied, its removed from the table If the asset is blocked, it stays in the table, with the blocked status
One problem to consider is how to handle inspecting assets. For example it would be good to be able to disassemble scripts in the browser to inspect what they're doing, or preview a model. But that's way way way out of scope.
One problem to consider is how to handle inspecting assets. For example it would be good to be able to disassemble scripts in the browser to inspect what they're doing, or preview a model. But that's way way way out of scope.
This should be done in the frontend, my script decompiler can be compiled to WASM and should be fully capable of being a tiny ~80k wasm blob which just takes in an array of data from JS, and spits out a JS string of the disassembly. So the frontend would just have the user download the WASM blob, download the asset into memory, then run the WASM blob on the asset, and show the user the result
So Refresh shouldnt need to have any say in this