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?

  1. I believe this is a simple solution that could easily minimize the amount of spam for many Drupal sites.
  2. 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?

Comments

tstoeckler’s picture

The problem is with it being in contrib is that other contrib modules may not support the renaming of the paths

Can you elaborate on those problems, I don't understand that. Thanks!

nigelw’s picture

No problem. For example when using the Rename Admin Paths module one could change the user login page to say /let-me-in. However, if you also had the contrib module, Commerce Login Redirect enabled, it automatically redirects the user to user/login. And as such, the person would receive a 404. I ran into many issues like this while using Rename Admin Paths.

By having the ability to rename paths in core there is a consistent api for contrib developers to ensure that they use the user defined path. I am not saying that this couldn't be solved in contrib but it would be very hard to get all contrib modules to buy into it unless something like this was in core.

marcingy’s picture

Title: Proposal: Simple Spambot control in Drupal 8 Core » Add a Simple Spambot control in Core

Lets remove d8 from the title code freeze is fast approaching and it seems unlikely this will make it in unless a patch emerges very quick;y

tstoeckler’s picture

it automatically redirects the user to user/login

Hmm... I think I would rather have something hook_url_outbound_alter() equivalent that works for redirects than the ability to arbitrarily rename paths.
Unless I'm mistaken that's a legitimate feature request:
With hook_url_inbound/outbound_alter() we are able to redirect a request from /foo to /node/3 and display links to /node/3 as /foo. But if I do $form_state['redirect'] = 'node/3' I have no way to act on that. Hmm...

tstoeckler’s picture

Issue summary: View changes

add some more details

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Active » Postponed (maintainer needs more info)

Wonder if this is still a desired for D10?

longwave’s picture

Version: 9.5.x-dev » 11.x-dev

The problem described in #2 should be solved in most cases if the routing system is used to generate URLs. In D7 we had to manually generate URLs by concatenating strings, but now we can specify a route name and arguments and the correct URL will be generated even if it is different to the default.

Rename Admin Paths in contrib is available and widely used for those that do need this feature, but I'm not sure there is a good argument for merging it into core as it's not needed or wanted by many sites.

quietone’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

Nearly two more years and no confirmation that there is interest in this. Therefore, closing this.

If there is interest in this re-open the issue and add a comment. Or open a new issue and reference this one.