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?
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?
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.