Take the 2-minute tour ×
Drupal Answers is a question and answer site for Drupal developers and administrators. It's 100% free, no registration required.

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

share|improve this question
    
Thank you Clive and Gisle, your points have taught me a lot. –  MrPaulDriver Mar 30 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 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 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 at 17:13
add comment

2 Answers 2

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.

share|improve this answer
add comment

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.

share|improve this answer
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 at 14:39
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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