The InspIRCd Project
Home | Developers | Wiki | Forums | Bug Tracker | SVN | Download | Blog
Personal tools

Development/Extbans

From Inspire IRCd (InspIRCd)

Jump to: navigation, search
Development
This page has been marked as Development Material.
Information posted here may be subject to change and/or only available in unstable versions of InspIRCd.


Contents

Proposal for extbans in InspIRCd 1.2

Introduction

The following document outlines how I think we should implement extbans. It is by no means a complete spec, just throwing some ideas against the wall to see what sticks.

First up, what are extended bans: Extended bans are a ban which is more than a ban. An example of this might be a 'ban' which blocks matching users from changing their nickname (in Unreal, +b ~n:blah!blah@blah, or something - charybdis uses +q for this purpose. Ours will be +B n:maskhere, etc.) Ideally, we can also come up with some way to integrate extban providers into +eI, for a more interesting setup, though this might be going too far. (+BE n:*!*@*.aol.com n:mike!*@*.aol.com).

Architecture

Extended bans should be implemented in a similar structure to how we have styled other such services: through a provider, and modules hooking the provider.

i.e.: Provider implements +B, intercepts the adding of masks, strips off the prefix character and colon, checks the mask is well formed, and hands off the extban to the child module implementing that particular extban. The provider should probably handle storing of the lists of bans, so as to reduce the amount of code duplication. The sole purpose of the child module(s) would be to handle the hook(s) they needed to, something like..

  OnAddExtendedBan(userrec *adder, char bantype, char *mask)
  OnDeleteExtendedBan(userrec *adder, char bantype, char *mask)

  constructor()
  {
	/* XXX - do we need more params here? */
	ServerInstance->ExtBan->AddBanHandler('n', "m_extban_nonickchanges.so");
  }

  OnUserPreJoin(...)
  {
	if (ServerInstance->ExtBan->IsBanned('n', u))
	{
		/* deny join */
		return 1;
	}
  }

Okay, this is wrong.

We need a class from which extended bans derive, containing things like parameter validation.. the ban char.. etc

Ban types

  • n - no nickname changes
  • q - quiet ban
  • r - realname ban (I'm unsure about this one, maybe third party.. would be handy to block cgiirc clients)


Other modules could also be modified to use an extban:

  • R:foo!lol@bar#alternativechan (m_banredirect)