As the number of Drupal sites increases, the number of bots out there will target Drupal sites. There are many ways in contrib to minimize this. However, many of them have their downsides as well.
- Add captchas and they disable your sites caching and your real users will hate you for making them fill out captchas every time
- Add a hidden form validation fields and bots will ignore it.
- Add a third party service to validate submissions and it will punish real users as these services tend to err on the side of spam.
- Block their IPs and they will just use a proxy
- Add time-based form submission control and this too will disable caching.
The list goes on...
What I am proposing is:
1. A simple setting in core where a site builder can define a new path for admin/*user/* and node/add/* and comment/reply/*. e.g. My new admin path is for managing users is now backend/people
2. Ensure redirects are not added from admin/*user/* and node/add/*. Kind of makes this approach pointless as were just sending them to the new alias.
3. A consistent solution in core that contrib modules need to use to define whatever pages they wish to add.
A proof of concept can be found in the contrib module Rename Admin Paths
This small module just implements hook_outbound_alter and hook_inbound_alter to rename paths.
Why does this need to be in core?
- I believe this is a simple solution that could easily minimize the amount of spam for many Drupal sites.
- The problem is with it being in contrib is that other contrib modules may not support the renaming of the paths. If a solution like this were in core then it would "guarantee" that every contrib module would support it.
Essentially, every drupal site out there would have different admin paths making drupal less of a target for bot writers. Why write a bot that can only hit a site or two?