IntellectualSites
Fix matching forbidden types in set component command
Overview
Gets rid of problems such as 'grass_block' matching 'grass' if 'grass' is a forbidden type.
Fixes [no issue report] (see below)
Description
Create a clean install of PlotSquared, claim a plot, remove all of your PlotSquared permissions and give yourself plots.set.*. Now run /p set floor grass_block. You'll get the error:
You are not allowed to generate a component containing the block 'grass'.
This pull request aims to resolve this.
Checklist
- [x] I included all information required in the sections above
- [ ] I tested my changes and approved their functionality
- [x] I ensured my changes do not break other parts of the code
- [x] I read and followed the contribution guidelines
The reason we switched to contains was because we don't process stuff such as block states, so that "grass[]" wouldn't be a bypass. The only real way to get around this would be by using regex to extract the actual block type from the pattern. We opted for the current solution as it would indeed cover all cases, but it could probably have been handled better.
Hmm, so the set command actually supports all WE patterns, which means something like /p set floor hand works if grass isn't in the disallowed-blocks section of the WorldEdit config and you have grass in your hand.
We need to handle that differently. As most patterns are either RandomBlockPattern, RandomBlockStatePattern or some instance of BlockStateHolder, we could probably check those instead. That way, we might have issues with custom patterns provided by third party plugins, but as you stated, we have issues using the current way too.
Well that'd also affect #clipboard. The solution to that would be to parse the pattern without supplying a player, but then we lose all context based patterns.
The DefaultBlockParser (see here) uses WorldEdit's disallowed blocks config option if the player doesn't have worldedit.anyblock to filter out any bad blocks. I added a proof of concept commit that exploits this. Sadly not all pattern parsers use the disallowed blocks config option (is that a WE bug?).
Maybe it would indeed be best to just check the parsed pattern explicitly. Although currently WE doesn't allow you to check which blocks are used in e.g. RandomPattern because all fields are private and there are no public getters...
I had that idea too, but there's no good way to iterate over all blocks involved in a pattern. The only way I could think of, which sounds awful, would be to manually go through every block that would be updated and check what the pattern returns. Not a very pleasant thought, lol.