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?
Comments
Comment #1
tstoecklerCan you elaborate on those problems, I don't understand that. Thanks!
Comment #2
nigelw commentedNo 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.
Comment #3
marcingy commentedLets 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
Comment #4
tstoecklerHmm... 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...
Comment #4.0
tstoeckleradd some more details
Comment #17
smustgrave commentedWonder if this is still a desired for D10?
Comment #18
longwaveThe 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.
Comment #19
quietone commentedNearly 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.