Maintain multiple blacklists

I find that people are already having a hard enough time figuring out the difference between the IP block, punishment list, and DNS realtime lists, in addition to the core access rules. A different list for each punishment seems like a lot of config options. Any particular reason to have sub-levels of punishment instead of just a "I'm going to punish you now" category? The funny part about misery was that it could be any one of the punishments at a time.

To be honest I have trouble understanding why the IP ban list and blacklists are two different lists with a different UI.

I don't think you understand my suggestion, I don't mean a list for each punishment. I mean arbitrary lists with arbitrary meaning.

So you create 5 categories of blacklist

1) Banned/Blocked IPs
2) Shunned/caved IPs
3) Misery/Punishment 1 (light)
4) Misery/Punishment 2 (aggressive)
5) No default action - will use custom code to display these IPs somewhere

At the moment if I want to use Troll blacklists for the purpose of white screening some IPs, I cannot use the Troll blacklist for any other purpose without also causing white screens for those users, because it's a single list.

By default the blacklist would work much as it does now, with just one category of blacklist, so extra options wouldn't be a complication for administrators.

I'll give you a simple practical example. I want a blacklist for trolls I will use Misery on, and a blacklist for trolls I will use Cave on, but not both on the same users :P

I've also raised this issue with the blacklist module http://drupal.org/node/504366

Lets just discuss it in one place:

The problem, and this was the inspiration for blacklist is that some lists are due to their structure very query unfriendly. For example in Drupal 5 the core drupal_is_denied query a) runs on every single pageload, b) can not be indexed. Once you have ~100 rules in there, it really shows. Here the idea is that those rules that dont need to fire every time can be moved away from the core, and thus will be fired less frequently. In our site's case this is applicable for every single rule.

I don't really see the need for an API, because its not too difficult to maintain the masks, I would need to rely on a third party module for my core functinality, and would i happen to want to add extra fields either i wait until it gets applied to that API, or I would need to use JOINs (for a dataset I could handle in one table at all).

What would make sense to me however, is to have one module that handles all the access related stuff. The admin could simply select what stage the rule should kick in. Originally i wanted to have blacklist as part of troll, but then I found it simpler to just make our code public first then work on a merger.

At the moment if I want to use Troll blacklists for the purpose of white screening some IPs, I cannot use the Troll blacklist for any other purpose without also causing white screens for those users, because it's a single list.

Correct me, but what keeps you from adding a WHERE condition and an extra field type into the table specifying what type of entry you're looking for? Of course if you have conflicting rules, like an allow and a deny rule for the same ip then you have a trouble, but a user just shouldnt do that (that reminds me to add a form validation for this check).

As a summary: my biggest worry is performance. I have seen how slow the generic core query can be, lets not repeat it.

The problem, and this was the inspiration for blacklist is that some lists are due to their structure very query unfriendly. For example in Drupal 5 the core drupal_is_denied query a) runs on every single pageload, b) can not be indexed. Once you have ~100 rules in there, it really shows. Here the idea is that those rules that dont need to fire every time can be moved away from the core, and thus will be fired less frequently. In our site's case this is applicable for every single rule.

Not sure I follow. You mean if you've banned over a 100 addresses the page loads start to slow down? Wouldn't this be a problem ALREADY without my idea?

I don't really see the need for an API, because its not too difficult to maintain the masks,

Well it is difficult to maintain the masks, so there is a need for an API - even if it's just a database table I can query. Everytime I write a module that has to do soemthing with IP addresses I have to reimplement the same blacklist thing again? It's pretty annoying for users too to have to look for different ways to enter IP addresses.

I would need to rely on a third party module for my core functinality, and would i happen to want to add extra fields either i wait until it gets applied to that API, or I would need to use JOINs (for a dataset I could handle in one table at all).

I don't know why you'd need extra fields. All you need to track is the IP address, and the category, maybe an ID, and some serialized data that isn't important in queries. Yes you can get more data from other tables with joins, that is not a problem, we do it with nodes. The point is there would be a single place for administrators to do all this crap in the backend of their site.

Correct me, but what keeps you from adding a WHERE condition and an extra field type into the table specifying what type of entry you're looking for?

That's my whole point, there is no 'type' field to do this with. My suggestion is to add a 'type' category thing so you can classify the masks/ips. In this way the lists could be configured seperately - I may have one group of masks I ban, another I simply redirect, or prevent anonymous postings from.

In summary: Basically the way you've got your modules set up at the moment is if the Views module only let you create a single view, or if CCK only let you create one field.

Not sure I follow. You mean if you've banned over a 100 addresses the page loads start to slow down? Wouldn't this be a problem ALREADY without my idea?

Not if the database table is separate. If I would use the same table for both access blacklist and login blacklist it would be substantially slower, because the access request fires on every page, the login request fires on login only, and the table to process is larger.

Perhaps it is my unfamiliarity with the functional features of Blacklist, but I don't know what an 'access blacklist' and 'login blacklist' refer to. Anyway I'm unsatisfied with the response I've received on this topic, and may have to start my own project to maintain lists of IP addresses and users for various purposes.

I'm not familiar with the blacklist module, but I can say for Troll, there are two very specific blacklists, hard-coded for specific purposes. You could abuse them as a blacklist for another purpose, but they do not currently have a clean or APIish way to have dual purposes to tag an IP address A for Misery, B for Cave, and C-F as misery and Cave. That would be new functionality for Troll. I'm allowing you access to Troll if you desire to make a home with it. Blacklist is a good alternative to turn into an API since at least its name fits your intentions. I think there are enough access control modules around to join up with one rather than create an even larger confusing pool of modules.