I would like to suggest that the ban control in Links SQL be taken to the next level, and be made a little more admin friendly.

• Move the banned IP list from the settings (tiny text box for list), to a banned.txt in the template directory. This allows the admin to continue to modify the list from the admin panel, but in the much larger template directory text area. Also, the user can more easily backup their banned list at the same time they are backing up their templates. Lastly, a few examples of usage (wildcards, IP's, http ) could be put into the default banned.txt that ships with new installs. Obvious bad IP's could be used for the examples.
• Allow wildcards in the banned list (I can't say for sure or not if this is working in the list - maybe someone could confirm this).
• Perhaps a 2nd level of user banning, so they can continue to search, but not submit.

My banned list is becoming difficult to maintain as it has grown so large. I do not have the luxury of server wide ban control as this particular web site is virtually/remotely hosted.

Also, I notice Links wishes to use the banned message in the language file rather than the banned.html. Is there a setting issue with this?

Thanks.


http://www.iuni.com/...tware/web/index.html
Links Plugins

I don't think that exporting the BANNED list to a text file would be efficient. May be a spanning set of results within a template would be fine. But I think that exporting the list from a database table to a text file is unncessary because how would you keep that text file updated?? Querying straight from a table that is automatically updated is better, IMO.
========================================
Buh Bye!

Cheers,
Me

I don't know that it is stored in any table. I am assuming that the banned list is stored in Links's configuarion file.

So I can't see why moving the list to its own text file wouldnt be more effecient, especially for the admin (in particular beginers), who don't know where links stores its configuarion settings.

Link SQL has a nice template system, where you can update files easily right from the user templates editing text area box. This is superior to a tiny text box which currently exists in the admin settings. So you are in fact updating in the same fashion (it currently is not automated - how could it be, you have to tell it who you want to ban). What I am suggestion here, is it be moved from the settings to an area which is more accessible for beginners (template area rather than config file), and into an larger text editing box which is still accessible from the admin area (template editor).


http://www.iuni.com/...tware/web/index.html
Links Plugins

Well, the IPs should be stored in a table (I have them stored in a table along with banned domains in a separate table) and it is much more efficient than using a flat file, which storing them in the configuration file is a flat file.

My suggestion would be to store the IPs in a table and then query that table in whatever template you envision using.

Understand?
========================================
Buh Bye!

Cheers,
Me

>>
Move the banned IP list from the settings (tiny text box for list), to a banned.txt in the template directory. This allows the admin to continue to modify the list from the admin panel, but in the much larger template directory text area. Also, the user can more easily backup their banned list at the same time they are backing up their templates. Lastly, a few examples of usage (wildcards, IP's, http ) could be put into the default banned.txt that ships with new installs. Obvious bad IP's could be used for the examples.
Allow wildcards in the banned list (I can't say for sure or not if this is working in the list - maybe someone could confirm this).
Perhaps a 2nd level of user banning, so they can continue to search, but not submit.
<<

I think it should probably be an sql table rather than flatfile, escpecially if you want to ban certain users from performing certain tasks...using an sql table would just be a little bit easier to manage and would make it easier if you were to write a ban related global for some reason. For example if you wanted a global to list the most recently banned user, then loading a text file is more effort than using the $DB object.

It sounds like something which could be achieved by a plug-in perhaps... but it would be nice if this could be implemented in to the core links program.

A little more "Ban Management" wouldn't go astray.


http://www.iuni.com/...tware/web/index.html
Links Plugins

Yeah I guess a plugin would be a good way to do it unless Alex built it in.