REQ :: MODULE - Restrict user command

[drake]

The idea is to restrict user commands . i'm expecting an official module( may be a feature for the next release) that would

1. Restrict some of( could be any ) the user commands to OPERS ONLY
- lets say /module command , you dont want to let every1 know how you protecting what... kiddies always find a new way to get u down.

2. Control command flood somthing similar to limiting nick change
-lets say /whois or /list command, it would be better idea to limit them to reduce server responses to junk.

i got a third party module "cmdflood" - by Angrywolf , In the document it does part of it i.e. it limits any commands you want but it doesnot restrict anycommands you want. Unfortunately the module didnt work for me... i ddint have any errors in compilation and seting directive. but when i was testing issueing those limited commands over and over again as non-oper it didnt do anything for me if any of you can figure out if i've mistaken somwhere please let me know

Another option , i had to low client recvq which basically low the ability to send any thing from client side. but our target was to reduce repeated /commands only not all of 'em.

I hope our coder will understand the necessity of it and help us as they can. Many of us will appreciate for sure.

------ Thanks In Advance.

[Jobe]

Just a point about the /module command, the whole idea as far as i am aware is so users can see if you are using modules such as m_spy to invade their privacy or other such modules which most users wont want to be on a server that uses them.

Another problem which would have to be address is commands such as NICK which would have to either not be restrictable or only be restricted after intial connection registration (PASS/NICK/USER)

[Stealth]

This has actually been suggested as an Unreal feature in the past. The report can be found here: http://bugs.unrealircd.org/view.php?id=2201

Yet, just like everytime this has been suggested, you don't tell us what these "good reasons" are! I see no good reason, I just see problems:

MAP - It's useful to be able to find another server on the network
LINKS - It's useful to be able to find another server on the network
LIST - How do you know what channels to join?
WHO - *MANY* clients use this for their IAL features, which would now be broken
LUSERS - Auto sent on connect, some clients expect this and require it to complete a connection
AWAY
HELPOP - How is preventing users from receiving help a good thing?
TIME - What about when I need to know what timezone the server is in, say for a /whowas reply?
DNS - Users can't do anything with it anyway, so what's the big deal
SETNAME - /quit | /realname MyNewName | /reconnect same effect, so what's the problem?

This will *definately not* be added unless someone can give me a very good reason why it is needed. Since this was first suggested over a year ago, I still have received no such reason but I am always informed that "good reasons" do exist.

It always comes down to:
A) There is no good reason
B) People trying to hide botnets

Look at the facts:
- Restricting MODULE can hide the fact you're using a spy module or other abusive module (such as sendraw, m_uline).
- You might have a reason to restrict WHOIS, but modes and commands can hide just about any information in WHOIS.
- Again, restricting LIST can be done with modes.

Also, if you look at the Unreal structure, it is easy to disable commands, but I will not get into that. If you're unable to figure out how, then you have no business disabling commands.

There are also ways of limiting server responses, but the defaults should be fine to keep people from lagging. Unreal monitors it's own bandwidth usage, and will disable certain commands when the bandwidth exceeds optimal usage.

It's all in the documentation, so RTFM