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!

CommentFileSizeAuthor
octopus_log.txt554 bytesjeremyr
o1.octopus.cnf_.txt985 bytesjeremyr
barracuda_log.txt1.23 KBjeremyr
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

omega8cc’s picture

Status: Active » Closed (works as designed)

This 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:

###
### 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;
  }
}
jeremyr’s picture

That's perfect. Thanks!

If you end up at DrupalCon Portland I have a beer with your name on it.

omega8cc’s picture

Category: support » bug
Status: Closed (works as designed) » Needs work

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

jeremyr’s picture

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

omega8cc’s picture

Yeah, 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.

jeremyr’s picture

Perhaps off by default but easily enabled for those who self-host?

omega8cc’s picture

Status: Needs work » Fixed

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

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

primeworks’s picture

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

jeremyr’s picture

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