If all my membership functionality is handled on the front end via an addon like User or Freemember, can I just delete EE's built in member profile templates?
What do you think? Would that help prevent spam accounts?
ExpressionEngine® Answers is a question and answer site for administrators, end users, developers and designers for ExpressionEngine® CMS. It only takes a minute to sign up.Sign up to join this community
The best way I've found to eliminate bot attacks is with the Snaptcha add-on. It's very unobtrusive and supports just about every other third-party user and comment add-on, like Solspace User and Freemember.
If you aren't using EE's Member Profile Templates, it's probably a good idea to hide them. You can't "delete" Member Profile Templates per say, but you can randomize the 'Profile Triggering Word' with a config variable making it impossible to guess. This would prevent spam bots that are trying to exploit the built-in member registration form (index.php/member/register).
Here's an example of this Focus Lab's EE Master Config:
/** * Member-based settings */ $env_config['profile_trigger'] = rand(0,time()); // randomize the member profile trigger word because we'll never need it
Here's an example from the NSM Config Boostrap:
// Create a random string for the member profile trigger 'profile_trigger' => '--sdjhkj2lffgrerfvmdkndkfisolmfmsd' . time(),
If you wanted to add this directly into your
config.php file, you could use this:
$config['profile_trigger'] = rand(0,time());
No, even if you do delete them. People will custom target to whatever signup method you dream of.
Your anti-spam thoughts should be focused more along the lines of: "What can a freshly registered user do that can be considered spam and how can I change that to at least be harder to do in 5 seconds?"
Spambots are definitely targeting the default member/register path for EE. I have a client's site that uses third party member registration add-on for EE, but despite hardening that, we were still seeing lots of spambots signing up on the site.
It turns out they were going right to the default member/register path and registering that way. You can either change the location as above, or do what I did, which is just set up an Apache redirect that goes from member/register to the actual registration form/page.