5

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

  • Thank you Clive and Gisle, your points have taught me a lot. – MrPaulDriver Mar 30 '14 at 13:49
  • If your are not a coder and don't want to become one, don't write PHP code regardless of where you write and store it. – Pierre Buyle Mar 30 '14 at 14:41
  • 1
    Copy-pasting is a way to write code (IMHO, a bad one). Once you copy-paste code into your site you become the maintainer of that code, the code becomes your responsibility. There will no third-party maintenance for that code, no update, no security audit. Once you do it, your are on your own. So you become the de-facto writer of this code. You cannot hide behind "I didn't actually understand this code, I just copy-pasted it" to avoid being responsible for it shortcomings. Don't write code if you don't want that responsibility. – Pierre Buyle Mar 30 '14 at 15:10
  • I don't disagree Pierre, especially with your points about security. That said, posting the code here on stack exchange is a kind of peer review, which I am sure would have alerted me to any serious problems. – MrPaulDriver Apr 30 '14 at 17:13
5

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.

4

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.

  • 1
    While I agree that bad programmers (be definition, as soon as someone write code, (s)he is a programmer, so there is no such thing a non-programmer written code) will write insecure code regardless of where the code is stored. The chance of writing invalid code in a bare bone HTML textarea is a lot higher. And because the code is stored in the database, the programmer will never be able to move to better practice such as code versioning or testing. So using the PHP module is not only a security risk, it also promotes/teach bad programming practices. – Pierre Buyle Mar 30 '14 at 14:39
0

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.

  • Thank you @Pierre.Viiens for this suggestion. My use of php filter continues to worry me every time I look at Drupal status report. I will explore your suggestion and report back. – MrPaulDriver Feb 25 '17 at 20:29
  • @MrPaulDriver Did you ever finish that "exploration"? – Pierre.Vriens Aug 29 '17 at 21:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.