About This File
Invision Community - Registration Username Filter
Version: 1.0.0 Platform: Invision Community 4.x Support: https://phoenix.lol/index.php?/files/file/427-invision-community-registration-username-filer/
Overview
IPS Registration Username Filter is a lightweight application for Invision Community that blocks user registration when the chosen username contains any forbidden substring defined by the administrator.
How It Works
The application intercepts the username validation process at the point of registration, profile name changes, and display name updates. When a user submits a username, it is checked against a list of forbidden substrings maintained in the Admin CP. If a match is found, the registration is rejected and the user sees an error message prompting them to choose a different username.
-
Matching is case-insensitive — the pattern
clusywill blockClusy,CLUSY,xXClusyXx, andmyclusyname123 - No wildcard characters are needed — any username containing the forbidden text is blocked
- The pattern list is cached for performance and updates instantly when changed
Features
- Manage forbidden patterns directly from the Admin CP under Members → Username Filter
- Add, edit, and delete patterns at any time
- Each pattern supports an optional internal comment for administrative notes
- Changes take effect immediately with no need to clear caches manually
Installation
-
Upload the
.tarfile via Admin CP → System → Applications → Install - Navigate to Admin CP → Members → Username Filter
- Add your forbidden substrings
Requirements
- Invision Community 4.x
What's New in Version 1.0.1 See changelog
Released
Issue 1 — Main (why the filter didn't work on registration)
The hook was only attached to validateUsername(), but IPS4/5 does not call this method during registration. It is only called when changing a display name via the ACP or user profile settings.
The registration flow goes through \IPS\Login\Handler → Member::createAccount() → Member::save(). That's why the fixed version adds two additional intercept points
// Intercept on account creation (registration)
public static function createAccount( $values ) { ... }
// Intercept on save (any method)
public function save() { ... }
The validation logic is extracted into a dedicated method _ufCheckName(), which is called from all three points.
Issue 2 — Incorrect database read
Original code:
foreach ( \IPS\Db::i()->select( 'word_pattern', ... ) as $row )
{
$patterns[] = mb_strtolower( $row ); // $row is an array!
}
\IPS\Db::select() returns arrays, so $row is ['word_pattern' => 'spam'], not a string. An array was being stored in the cache, causing mb_strpos to fail silently. Fixed
$word = is_array( $row ) ? $row['word_pattern'] : (string) $row;
Issue 3 — Minor: word_added was overwritten on edit
On edit, the data array included 'word_added' => time(), which reset the original creation date. Now word_added is only set when inserting a new record.
