Main menu

You are here

Feed aggregator

I’ve recently been reviewing a few security related patches and it soon became apparent that many developers make the same mistakes over and over in regards to best practices for security in Drupal. So below, a very short post on the common mistakes and solutions.

Correct usage of t()

Use the right placeholder for t(). You should be using "% and @" which are both escaped to protect against Cross Site Scripting vulnerabilities. Whenever you use "!" as a placeholder, double check the content has already been escaped.

Escaping Output in #markup

If you’re providing a custom field, widget and formatter you need to make sure that any content coming from the admin is correctly escaped. For example, you’re implementing hook_field_formatter_view() and doing something like:

In the 0.0.3 release, I overlooked one thing: that with builds on Windows, we would also get builds against what CRAN calls R-oldrel: the previous release, which cannot turn on C++11 via the simple CXX_STD = CXX11 declaration in src/Makevars (and which we need because use of Boost brings in long long which R can only cope with under C++11 ...).

So this new release 0.0.4 does nothing more than add a constraint in a Depends: R (>= 3.1.0) to avoid builds not being able to turn on C++11.

Getting submenu items to appear within the user edit area of Drupal has not always worked as I would expect from reading the documentation around hook_menu(). As it happens the user module provides hooks to make this quite simple.

In this example we would have a new set of tabs added to the User Edit page. The first is Account and is now presented because we have more than one tab here now. The second is Report Settings and it would have a URL like user/12345/edit/report_settings where report_settings is taken from the name parameter.

At this point we have a new menu item presented as a tab on the user edit page and clicking it takes us to a blank form with a submit button. I think this is due to the way menu items can inherit behaviour from parent menu items. We’ll be wanting to overload that behaviour though and present our own form. This can be done through hook_menu_alter().

Checking the keys of the array passed to hook_menu_alter() we should find that we have a new one called user/%user_category/edit/report_settings. We can edit this one to point it at our preferred form built using the Form API as usual.