CiviCRM Community Forums (archive)

I'm running CiviCRM 4.3.2 on Drupal Commons 6.28.

When I edit the 'Widget' tab on the configure a new Contribution page I get an error:

Permission denied error 403.

Requested page:
/civicrm/admin/contribute/widget

Referring URL:
http://test.nscfundalaska.org/civicrm/admin/contribute/membership?action=update&reset=1&id=10

Visitor IP Number:
nnn.nnn.nnn.nnn

Seems it runs once, to fill it out, but any time you go to edit the copy and hit any of the 'Save' buttons the error occurs and the edits don't make it to the DB?

Any ideas why?

What I see when I save is the contents of the 403.shtml file, which is in the quote in the first post.   The whole CiviCRM/Drupal Commons engine does not get presented.

I think that the issue stems from the form build for the widget tab.

On all other tabs, pressing the submit form button for that tap calls the URL:

/civicrm/admin/contribute/membership?action=update&reset=1&id=9

On the widget tab, the URL called is:

/civicrm/admin/contribute/widget

I think that the URL should be something like:

/civicrm/admin/contribute/widget?action=update&reset=1&id=9

So any insight as to where to look in the code base to see where this page get assembled would be appreciated.

Well I don't think Drupal 6 is supported in actuality, by the core team. Truth is that even if it were, I would tell you (if I was the team) that you need to test on pure vanilla Drupal, not Drupal Commons. Because maybe something in DC is causing a conflict....

Is your .htaccess different than the default Drupal one?

Can you ask your host for help?

In this case (and I suspect many others) it was an issue with mod_security and a specific exception put in place by hosting solved the problem.  I think this may also be in play when PayPal tries to return it's information.

Here is an explanation from my hosting provider AN Hosting:

-----

The issue in this case was due to a Server Configuration that is defined within ModSecurity and its ruleset. Unfortunately, the rule sets in place are not available to view on the server end. If you do notice any type of errors, especially a 500 Internal Server or 403 Forbidden error, please let us know so that we can review the server logs for any issues related to this security feature that is in place.

ModSecurity is an open source, free web application firewall Apache module. ModSecurity is deployed to establish an external security layer that increases security, detects, and prevents attacks before they reach web applications. It
provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis.

In some instances, legitimate connections, script, or tools/applications can be blocked by ModSecurity rules attempted to defend the server. It is better to avoid adding exceptions to these rules that defend the server because most
mod_security problems can be resolved by changing how an application or plugin performs, modifying a script, or reducing the size of files uploaded to your account.

We can send a request for a ModSecurity exception up to our next level of support, but it is a request and must be approved before being implemented on any account. ModSecurity exceptions when added are specific to a directory or
file, and are not added to the entire account. Similarly, since exceptions are added by the rule, we cannot simply except a user's entire account from all ModSecurity rules. In essence, a specific rule running from a specific directory
or file must be triggered before we will be able to consider applying any exceptions to an account.