fix: make contains a substring match and compare authors by key - #28
Merged
Conversation
…y key Both problems are in evaluateRule and neither can fire today. The shipped rulebook holds only rating and epoch_support rules, and nothing exposed to the frontend creates a rule, so no author or category rule can exist yet. They would have bitten whoever wired a rule editor. The contains arms for author and category were each a copy of their eq arm, so the operator did exact equality. A rule saying contains games could never match games/arcade. An author rule compared the app's stored author against a value the user typed. For a TELA app the stored author came from the DVM, which always renders the dero1 form because ADDRESS_STRING builds through rpc.NewAddressFromKeys and leaves Mainnet true, since consensus cannot depend on which network a node believes it is on. A user on a simulator copies deto1 out of their wallet. Addresses are bech32, so the prefix and the checksum both differ and the rule never matches its own author. sameINDEXAuthor already decodes both sides and compares keys, so eq now uses it. contains stays a text match, because a substring of an address cannot be decoded. An author rule naming a whole address has to use eq. Tests cover both renderings in both directions, a different author across networks, a rule value that is not an address, and substring vectors chosen so an equality compare rejects them. Mutation checked: reverting either fix fails its own test with the build still clean.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two problems in evaluateRule, both filed as issue #27. Neither can fire today, because the shipped rulebook holds only rating and epoch_support rules and nothing exposed to the frontend creates a new one, so no author or category rule can exist yet. This closes a trap before someone wires up a rule editor.
The contains arms for author and category were each a copy of their eq arm, so the operator did exact equality. A rule saying contains games could never match games/arcade.
An author rule compared the app's stored author against a value the user typed in. A TELA app's stored author came from the DVM, which always renders the dero1 form because ADDRESS_STRING builds through rpc.NewAddressFromKeys and leaves Mainnet true. A wallet on a simulator shows deto1 for that same key. Addresses are bech32, so the prefix and the checksum both differ and the rule never matched its own author. sameINDEXAuthor, added in #26, already decodes both sides and compares keys, so eq uses it now.
contains stays a text match, because a substring of an address cannot be decoded. An author rule naming a whole address has to use eq.
Tests cover both renderings in both directions, a different author across networks, a rule value that is not an address, and substring vectors chosen so an equality compare rejects them. Reverting either fix fails its own test with the build still clean.
content_filter.go has pre-existing gofmt drift in its const block and struct tags. I left it alone so the diff stays readable.
Closes #27