Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I have a site that I'm migrating to Aegir and have discovered that when an anonymous user visits the node add form (node/add/machine_name) they receive a 403 error served up by Nginx. On this particular site I really do need anonymous users to create nodes, at the end they are presented with a payment gateway.
So, I first want to confirm that the 403 is standard behavior. If it is, that's totally fine with me because it seems to make sense. But, is there a way to override it on a site-by-site basis?
Thanks again!
Comment | File | Size | Author |
---|---|---|---|
octopus_log.txt | 554 bytes | jeremyr | |
o1.octopus.cnf_.txt | 985 bytes | jeremyr | |
barracuda_log.txt | 1.23 KB | jeremyr |
Comments
Comment #1
omega8cc CreditAttribution: omega8cc commentedThis prevention has been introduced by design, after too many reports about sites turned into spam machines because of these permissions left for the world.
You can override it using standard how-to, with config like:
Comment #2
jeremyr CreditAttribution: jeremyr commentedThat's perfect. Thanks!
If you end up at DrupalCon Portland I have a beer with your name on it.
Comment #3
omega8cc CreditAttribution: omega8cc commentedIt looks like we should remove this too strict policy, since some workflows may require ability to create a node of some type by anonymous visitors.
Comment #4
jeremyr CreditAttribution: jeremyr commentedGenerally speaking, I like the idea of locking down those forms. I don't think it's actually a problem the way it's currently configured. I originally wasn't sure if it was default behavior, so it might be a matter of educating rather than getting rid of it.
Maybe the hints document could be a little more verbose about those miscellaneous items??
Comment #5
omega8cc CreditAttribution: omega8cc commentedYeah, but hosted clients have no access to this extra config and can't add their own overrides. But they can request them, of course. We will see how many complaints we will collect - so far I have seen it from one of our clients.
Comment #6
jeremyr CreditAttribution: jeremyr commentedPerhaps off by default but easily enabled for those who self-host?
Comment #7
omega8cc CreditAttribution: omega8cc commentedFixed as suggested in http://drupalcode.org/project/octopus.git/commit/03d1a3e - thanks!
While we still deny access to node/add* for not logged in users by default, we have moved the deny/allow logic from Nginx to global.inc level, where we have added support for special control file: sites/foo.com/modules/allow_anon_node_add.info which allows to open the access for anonymous visitors on the fly, per site. Note also that currently the active deny rule doesn't throw a generic 403 access forbidden - it simply redirects to the site homepage.
Comment #9
primeworks CreditAttribution: primeworks commentedI know this issue is closed but i've tried applying the fix and it's not working. I suppose I'm doing something wrong.
I started by creating a file in /data/disk/EDIT_USER/config/server_master/nginx/post.d/nginx_force_include.conf and adding the script
=============================================================================
###
### Allow node/add/machine_name for the world and block only bots
###
location ^~ /node/add/machine_name {
location ~* ^/node/add/machine_name {
if ($is_bot) {
return 403;
}
try_files $uri @drupal;
}
}
=============================================================================
This didn't work. I renamed it to the file nginx_vhost_include.conf and that didn't work. Could someone please help me out?
Comment #10
jeremyr CreditAttribution: jeremyr commented@primeworks Assuming you are running the latest version of BOA you only need to add a control file. The change is outlined above in comment #7 and the info can be found here also: http://drupalcode.org/project/octopus.git/commit/03d1a3e.