0. INTRODUCTION

  Administering public forums is notoriously nightmarish.

1. BAN TYPES

  The ideas for slowing down Evil People are as follows:

1.1 Account Suspension

    When the account tries to log-in all they see is an "Account Suspended"
    page.

    The site can be viewed while logged out (i.e. guest user)

1.2 Ban-by-IP

    This can take varying levels of restriction:

1.2.1 Restrict Posting by IP

    Prevent user(s) from matching IPs creating new threads, replying to
    existing threads or editing existing posts.

1.2.2 Restrict Login by IP

    Prevent user(s) from matching IPs using the login functionality

1.2.3 Restrict Sign-Up by IP

    Prevent new accounts being created from matching IPs

1.2.4 Restrict All Access by IP

    Matching IPs are shown the "Evil People Got You Banned" page.
    This is pretty harsh, and should be saved as a ast resort .. if
    implemented/used at all.

2. KNOWN ISSUES

  There are the usual issues of people running through proxies, catching
  people we didn't intend to, or being used by banned users to circumvent IP
  based bans.

3. CONCERNS

3.1 Performance

    Will IP checking for every request have a noticable, negative, effect on
    application performance?
    We could store information in-session for IPs we discover to be affected,
    but we then have the following issues:
        - we're still doing a lookup every hit for the majority of hits (the
          Good people)
        - if we escalate or modify a user's IP restriction it won't take
          effect, since we already have them session-flagged for something
          lesser.

4. POSSIBLE IMPLEMENTATIONS

4.1 Net::IP::Match::Regexp

    This looks like a useful module for providing (CIDR - a.b.c.d/x) IP ranges
    and matching IPs that live in those ranges.

4.2 IP matching

    In (3.1) concerns were raised regarding a per hit performance lookup.

    This may be reduced by reducing the number of lookups and queries; instead
    of a growing set of records in a table - one for each new match - we could
    make use of the create_iprange_regexp() feature in Net::IP::Match::Regexp
    and have one row for each ban-type.

    This should reduce database overheads, and hopefully simplify the IP
    matching.

    The interface may become difficult to use (in the initial) implementation
    if we offer a textarea to manage the ranges. This could be overcome in the
    future by having the interface split/format IP blocks on viewing, and
    compress to one string on saving.
    A small hit at admin time, instead of a per-hit overhead.

    We'd lose the ability to timestamp individual modifications, or provide a
    per-block rejection message.

4.3 Admin Action Tracking

    It would be useful for the application to keep a log of changes, with a
    comment written by the moderator, so that time and reasons for bans could
    be viewed by other admins.

    e.g.

      2008-02-13 08:25  Added r.s.t.u/x - they just kept on being abusive

    There might be an opportunity to establish the "diff" between the before
    and after IP list(s) and store those with the message. (list based maths?)

4.4 Admin permissions and roles

    We don't necessarily wish to allow all moderators the ability to perform
    anoy or all of the restriction actions.

    This will most likely introduce some kind of role based system;
    Catalyst::Plugin::Authorization::Roles?

    Methods can be added to ::Schema::Person to do various role checks;
    e.g.  can_suspend_account()
    [although, how can we use the Catalyst plugin be used from the Schema?]