• Advanced Poll 6.x versions - XSS Vulnerability

    During the weekend I discovered an XSS issue with the Advanced Poll module. I've made sure to provide a patch and submit this to the issue queue.

    I have actually submitted a few other SAs in the past, one of them was for the nice_dash module, which aims to provide a dashboard interface for Drupal administrators, but unfortunately it wasn't yet commited.


    Drupal Security Advistory - XSS vulnerability in Advanced Poll module versions 6.x-3.x and prior

    Project: Advanced Poll (third-party module)

    Version: 6.x-3.x and earlier

    Date: 2013-10-25

    Security risk: Highly critical

    Exploitable from: Remote

    Vulnerability: Cross Site Scripting 

    This module enables you to create advanced types of polls, such as binary and ranking poll, as the module calls them. The module did not sufficiently filter poll question titles for malicious JavaScript. This vulnerability is mitigated by the fact that an attacker must have permission to create or edit polls.

    Versions affected

    Advanced Poll 6.x-3.x and all prior versions


    Apply the patch

    Reported by

    Liran Tal <>

  • Media in Drupal 7 - presenting it in Drupal Camp Israel 2013

    I attended Drupal Camp Israel - 2013 last week, and presented there about Drupal 7 Media, which is very much the title of my recently published book by Packt Publishing.

    The conference organization was overall good, lectures flew smoothly, there were camera men video-taping the whole event so that's a nice plus to watch the offline lectures for people who couldn't attend the event. It was organized this year by Roy Segall and Anat Kahana. The conference started out with an opening panel, followed by Jonathan Sacksick from Commerce Guys, who attempted to break the language barrier and explain about E-Commerce in Drupal 7 and Commerce Kickstart in general. 

  • Drupal 8 module development #4 - creating a settings file

    This is the 4th of several on-going blog post series which aim to educate on the process of porting modules to Drupal 8 with real life examples by porting a popular Drupal 7 module to Drupal 8.

    In previous articles we have started with Drupal 8 initial module porting and worked our way about adding a route and implementing the settings form controller so that we can present an administrative UI for managing the various configuration options which the module exposes.

    Next up will be to create and define those configurations options. In Drupal 7 we used the variable system to save and load configuration options, thus calling variable_set() and variable_get() in our modules, and all of this configuration data was saved in the database just like the rest of Drupal's data storage. This brought clutter and quite some mess, where pure data is mixed with configuration information and such. Out of the necessity to deal with this in Drupal 7 we've turned into modules like Features, Strongarm and others, although none of these is an ideal solution. For this reason, Drupal 8 defined the configuration initiative which aim is to attack this problem and make this simpler. 

  • Drupal 8 module development #3 - adding a settings page - revision

    This is the 3rd of several on-going blog post series which aim to educate on the process of porting modules to Drupal 8 with real life examples by porting a popular Drupal 7 module to Drupal 8.

    In the previous article we introduced the configuration system and showed how to create a settings form, integrate with the configuration management system and enable our module to save it's configuration data using this system.

    As things still change pretty quickly in the Drupal 8 arena some of the items in the previous post are not valid anymore so while I've updated the code for our Global Redirect module on drupal/git, I wanted to post the revised and full and up-to-date (for now :)) version of the settings form:


  • Drupal 8 module development #3 - adding a settings page

    This is the 3rd of several on-going blog post series which aim to educate on the process of porting modules to Drupal 8 with real life examples by porting a popular Drupal 7 module to Drupal 8.

    Drupal modules often provide an administrator with a settings page so that various configuration options can be tuned and setup using the web interface. We will take a look at how we can create a configuration page and get to know some basic interactions with Drupal's new configuration system.

    In the previous article we briefly introduced the routing system, with adding a basic route. When that route is triggered Drupal will be searching for the settings form class implementation - Drupal\globalredirect\Form\GlobalredirectSettingsForm that we defined in the route setting.


    Let's begin by creating this directory structure of lib/Drupal/globalredirect/Form in the module's root directory and then create the form class GlobalRedirectSettingsForm.php which will contain the skeleton class:

  • Drupal 8 module development #2 - adding basic routing

    This is the 2nd of several on-going blog post series which aim to educate on the process of porting modules to Drupal 8 with real life examples by porting a popular Drupal 7 module to Drupal 8.

    In the previous article we looked into the very basic job of beginning a module's port to Drupal 8 and that was to update the module .info file. Next up, we will take a look at updating the routing system create a valid menu entry which will point to the module's settings page.

    In Drupal 7 and previous versions, it was required to implement hook_menu() and return an associative array with a list of parameters which define the menu entry, such as the routing path, the title, access permissions etc. For the Global Redirect module that menu entry for configuring the module looked as such:


  • Drupal 8 module development #1 - kicking off

    This is the first of several on-going blog post series which aim to educate on the process of porting modules to Drupal 8 with real life examples by porting a popular Drupal 7 module to Drupal 8.

    I've been following Drupal 8 development for quite a while, during which I helped a bit with the issue queue, posting some patches and did some general sanity testing to see what's the buzz all about. I'm a firm believer in getting your hands dirty if you really want to know what's going under the hood, and sometimes it's just not enough to "read about it". So with that said, I figured I'll pick myself some non-migrated yet Drupal 7 module and start working on that. That module turned out to be Global Redirect which isn't a terribly complex module so it makes a good starting point.

    After doing some good progress with the module, I have e-mailed Thomas, the module's maintainer and started collaborating on the Drupal 8 port together with Francisco and we're on our way to get that module up and running for Drupal 8. In doing this, it was important for me to port the module with a sequence of logically incremented commits which are building-up the module's port together so this will be easier for new comers to figure out from the commit diffs how the porting process begins.


    Getting your hands dirty: the .info file

  • Drupal 8 development - finding API changes through Drupal's Change Records

    When tackling a new framework or program code, in attempt to contribute and join the development effort, one may find it difficult to navigate through the set of APIs. That's where documentation comes in. This is the case with new comers to Drupal's 8th development branch as well, except we don't really have an official documentation up and ready at our disposal. While there are blog reviews covering different parts of Drupal 8 development you might find the most important or at least up to date information that you need at Drupal's Change Records.

    The Change Records are somewhat of a changelog list which is a bit more elaborate and may specify when was the change introduced, any open issues with it, where is its impact through-out the system and even examples of making use of the new API, if present.

  • Enabling slideshows in Drupal by converting PPT and PDFs

    One of the user stories we've been busy with at work was to enable a service similar to slideshare, where users are able to upload their presentations and we'll create a browser slideshow for it. This means that we accept various formats, like the popular .ppt presentation files, and locally convert it to something we can work with and display on standards web browsers like images. Doing this with online services like slideshare is definitely possible using their APIs but we need to keep these stuff in-house due to company policy and such, so my colleague David Madar had put together a list of open source tools to get this job done.


    Installing software

    The solution includes the following software stack:

    1. Gearman as a job server for running background tasks
    2. Openoffice, a python script and ghostscript, all for the purpose of accepting one input format and converting it to an output format as we desire (images for now).


    Installing Gearman

    In most cases I'd just grab the gearman sources with the required headers and supporting libraries but if you're working with CentOS then most packages are plain old, and secondly a pain to install if there's no RPM for it (yes, it's a rant). So if you're one of the luckiest men on earth to be given CentOS 5 to work with (unfortunately 5.3 to be exact) for this little experiement you can do:

  • OG Content Access

    Drupal has a flexible access control list (ACL) system, where it provides permissions and roles (also known as RBAC, Role Based Acess Control) per user. This eases administrators job by allowing them to group users into different classes or cateogories (roles) to create differentiation in user's capabilities. While this fits most web applications built on top of Drupal it doesn't fit them all.

    Drupal's fault at this is that it is designed to be very permissive by default. In most cases, this means that users are generally allowed to see everything (even though they may not be able to create, edit or delete). This is the case with Organic Groups as well. When users in a Drupal+OG website becomes a member of a community, they may not be able to create/edit/delete some content types, but they will definitely, by default, be able to see (have read permissions, per say) all of the content in that group.


Subscribe to Blog