-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@sitelock musing #1245
Comments
Another idea: change the access.cnf flatfile format from the current format to JSON (Continue to support reading the old one for backward compatibility) for easier loading and making it easier to support future extensions and additions. Instead of lines like
an array of objects like
|
I'd rather see it as an in-game object/attribute tree model rather than changing the format on a file. |
Another note so I don't forget. If/when adding ip masks, make ipv4 mapped ipv6 addresses like Maybe do this with wildcard patterns too if it looks like a ipv4 address in the pattern and the IP being matched against is mapped. |
It'd be nice to have multiple key:vals to sitelock, rather than treating it as one glob. And for non-http uses, adding multiple key:val types makes it expandable, e.g: For backwards compat, only use key:val type with |
I'm not proposing doing away with pattern matching rules, just adding other types of matches, if that wasn't clear. |
Yeah I'm doing the same, just want it to be explicit pattern instead of "Try all the patterns we have against this IP. And against this hostname. And ..." |
Being able to mark a pattern as just hostname, or just ip address, (Or just http request) is another enhancement that's easy to do. Adding it to the list. |
well to be clear, adding multiple patterns to a single rule would be ideal, especially for http. e.g: A single rule for |
Talk on
<Hardcode>
today about blocking TOR sites made me think about another of my hundreds of back burner ideas.Right now, sitelock records are stored in a text file (access.cnf), and loaded into a linked list. It's read at startup and after a
SIGHUP
(Along with a bunch of other stuff), and written every time a @sitelock is run. IP addresses and resolved hostnames are matched using wildcard globs or regular expressions.So, a few ideas:
SIGHUP
to get changes synced with the mush - for example, a cronjob that periodically updates a list of TOR sites. They just have to insert or delete rows from a table.The text was updated successfully, but these errors were encountered: