Is it safe to use php within a Rules condition?

Question

Using Rules I need a condition which checks if the logged in user has authored a given content type.

It seems that I need some custom php for this and I found the code below from a post on drupal.org, which works as required and my rule now does exactly what I want it to do.

I had to enable php filter (for User 1) in order to get the code in to my rule. But I have read that php filter should be disabled on production sites but find that my rule ceases to work if this is done.

I am not a coder and am need to know what is the best way to deal this situation?

https://drupal.org/node/2052241

Answer 1

The PHP filter uses eval(). eval() gets a bad rap because it can be used insecurely. This post on SO goes into detail on that.

The answer to your question is that it could potentially be insecure, depending on the input provided, and how you have things configured. So getting rid of PHP filter altogether would be the ideal resolution (as it pretty much always is).

Getting your code out of the database and into version controllable files is extremely desirable, and is always considered better practice than using the PHP filter.

The proper way to provide rules conditions is to create a custom module, and implement hook_rules_condition_info(). If you're not a programmer then that might be a bit daunting, but at that point it's up to you to decide whether the risks outweigh either learning to do it yourself, or paying someone else to do it.

Answer 2

The PHP-module and its associated PHP filter may create security holes when used improperly.

The main reasoning behind the advice you've read about having it disabled on production sites, and it being removed from core in Drupal 8, is that it lowers the bar for creating PHP, making is simpler for non-programmers and unskilled programmers to add PHP to a site's code base (in particular, PHP code that don't sanitize user input).

However, the main risk is that by enabling it, some unthinking admin may give access to the PHP-filter for all users (not only the trusted user #1).

Given improper use, the site can be compromised by any script-kiddie. By leaving the PHP module completely disabled, you've eliminated that risk.

However, that being said, the PHP-module is useful in some situations (as you've discovered), and I think that it is over-cautious to never having it enabled on a production site. As long it is only allowed for user #1 (i.e. the implictly trusted super-admin), and the PHP that is added is safe (for the record, the code proposed at Create a Rule to Evaluate If a Logged-in User Has Created Content of Type X is safe), then the site is not put in jeopardy by having it enabled.

Just thread carefully, and make sure you you know enough about Drupal to understand that the PHP-filter should not be enabled for "Filtered HTML" or any other text format that untrusted users are allowed to use, and that the code you add to the HTML-textarea using this feature must by itself be safe.

PS: Some people seem to think that it is somehow "better" to add PHP to a site by writing a custom module instead of having it in the database. IMNSHO, it makes little difference where you keep it. A bad programmer is unfortunately perfectly capable of creating unsafe PHP anywhere. Having unsafe PHP inside a file instead of inside the database will not save you if the PHP-code happens to be unsafe in the first place - even if you've paid somebody to create it for you.

Answer 3

What's included in the previous 2 answers is "true", but IMO there is yet another possibility to "deal with this situation" (as in your question). I.e. try to come up with an alternative solution that doesn't require any "custom PHP".

Have a look at this quote from "Create a Rule to Evaluate If a Logged-in User Has Created Content of Type X" (= the HowTo you linked to in your question):

... the SQL query checks the database for a user who has created one or more nodes of the type configuration_1. If one or more nodes exist for this user, the condition evaluates to false ...

Building a list of nodes using the Views module, with identical selection criteria, is rather straight forward (not further explained here). And if you then use the Views Bulk Operations (VBO) module to transform that view into a VBO view, you can use a Rules Condition "* Check number of results returned by a VBO View*" in which you can perfectly construct the Rules Condition you're looking for.

True, this requires 2 extra modules (which should be available in mostly any site anyway), but it requires zero custom code. And hence you avoid the need for the dangerous PHP filter.

PS: Have a look at "this answer" for an illustration of how this specific Rules Condition is used.