Allow blacklisting CIDR ranges

[dsaxton]

Enables CIDR blocking in case a spammer is using multiple IP addresses in a specific range.

$ cargo test
   Compiling noteguard v0.1.0 (/home/user/git-repos/noteguard)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.67s
     Running unittests src/lib.rs (target/debug/deps/noteguard-5c03b805e5f0ad1b)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/noteguard-9c26818f53f234ae)

running 9 tests
test tests::test_deserialize_input_message ... ok
test tests::test_blacklist_reject ... ok
test tests::test_blacklist_accept ... ok
test tests::test_blacklist_cidr ... ok
test tests::test_register_builtin_filters ... ok
test tests::test_load_config ... ok
test tests::test_whitelist_reject ... ok
test tests::test_run_filters_shadow_reject ... ok
test tests::test_run_filters_accept ... ok

test result: ok. 9 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests noteguard

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

[jb55]

On Sat, Jan 04, 2025 at 05:41:54PM GMT, Daniel Saxton wrote: Enables CIDR blocking in case a spammer is using multiple IP addresses in a specific range.

awesome. had the same thought!

[dsaxton]

On Sat, Jan 04, 2025 at 05:41:54PM GMT, Daniel Saxton wrote: Enables CIDR blocking in case a spammer is using multiple IP addresses in a specific range.
awesome. had the same thought!

Nice! Let me know if you think there's a better dependency than ipnetwork. I just realized that one hasn't been updated in a long time (not that it matters too much for this).

[jb55]

ideally we would parse the CIDR thing before so we don't have to do it for each incoming message.

the best way to do this would probably be some kind of trait with an associative type so that we convert it to the parsed version of the struct after deserializing. the associative type could just be itself if there is no difference in the parsed structure.

example:

trait NoteguardConfig {
  type Parsed

  fn to_parsed(&self) -> Self::Parsed {
  }
}

impl NoteguardConfig for Blacklist {
  type Parsed = ParsedBlacklist;

  fn to_parsed(&self) -> Self::Parsed {
    // note: I haven't tested this it's off the top of my head
    let ips = self.ips.iter().filter_map(IpNetwork::from_str);
    ParsedBlacklist {
      ips
    }
  }
}

Then we can do this automatically somewhere when we are reading the config.

[jb55]

Alternatively we can do custom deserialization directly on the type somehow, I haven't touched this code in awhile so the proper way to do it isn't floating in my head anywhere at the moment

[dsaxton]

Alternatively we can do custom deserialization directly on the type somehow, I haven't touched this code in awhile so the proper way to do it isn't floating in my head anywhere at the moment

Sorry for the delay here. I applied this suggestion and tests still seem to be passing. Was this roughly what you had in mind?

[jb55]

yeah that's great. thanks!

[jb55]

just need docs and then we'll be good to merge!

[dsaxton]

just need docs and then we'll be good to merge!

Docs updated 👍

[jb55]

holy crap sorry for the delay, found this at the bottom of my dev inbox