I've lived in New England my entire life, and if there's one thing that Yankees treasure, it's tradition. I'm no different, and yet today, I grudgingly decided that one tradition is not worth keeping.

Ever since I was a child, my family engaged in one of the most time-honored New England traditions of the autumn: raking leaves. Raking leaves is a noble chore. You get exercise and fresh air, your lawn benefits from being dethatched by the tines of the rake, and it instills a solid work ethic in the young.

It's a chore that I have always cherished. This year, however, I was rather dreading it. I just purchased a new home in September, and it has a substantially larger yard than my previous home. I knew that it would take me weeks to rake the entire property, and with a full time job, young kids, a wife, and everything else that keeps a family busy, I was trying to figure out how I could squeeze an extra 12 hours into each day.

Mostly out of curiosity, I decided to try a leaf blower. I'll categorically state that I find this to be cheating, but in the face of weeks of raking, I saw little reason to not give it a try. I'll have to admit, I was highly skeptical of the tool. As I mentioned before, one of the benefits of raking by hand is that the lawn gets a good dethatching; that is, all the dead grass and other material that forms a carpet right at the level of the soil and blocks nutrients from reaching the roots of the grass gets pulled up by the tines of the rake. I didn't see how a leaf blower would help with this.

At this point, I have to concede that the idea for the leaf blower was not mine. The leaf blower was a gift to me from my father, who is much wiser than I am. When he first gave it to me, I had no intention of using the thing for the reasons I had mentioned above. I have the unfortunate tendency to forget about things that I dismiss as useless, even if my determination regarding the usefulness of a thing is based on little or no prior experience. I don't know what it was about today that made me rethink my position on the leaf blower, but I was pleasantly surprised by its effectiveness.

As I mentioned, I have a large yard. Nearly two acres of level lawn, ringed by a thick woods of maple, oak, birch, and sumac. I was able to completely clear my backyard of fallen leaves in under an hour, a chore that would have easily taken me six hours had I resorted to my traditional techniques. The leaf blower was powerful enough to scrub the lawn and underlying soil clean. However excited I was about my progress and the ease of clearing the leaves, I could not help but feel sadness.

You see, I'm addicted to technology. I work with it every day, and run my life with it. The use of technology, even simple technology like a leaf blower, has implications. Using a leaf blower is a one-man job, and the tool is so loud, there's no chance for discussion and conversation while working. Furthermore, when you use a tool that cuts your work time down to next to nothing, the issue of work ethic is not even worth mentioning.

I was left wondering how I will teach all of these things to my sons. How will I teach them the value of sweat equity, the importance of physical labor and the satisfaction of putting your body to work with fantastic results? How can they learn the fine art of Yankee conversation, which occurs in short bursts, layered on top of physical work? The great New Hampshire author Noel Perrin described this very thing in one of his essays.

Sure, I can choose to abandon the leaf blower and go back to traditional methods. But as much as I have this choice, my Yankee sense of frugality forbids me from doing something that takes so much time when I have at my disposal the tools to get the job done faster leaving room for other things. Would I rather rake or spend the extra time with my sons?

As my father always reminds me, there's no such thing as setting aside quality time with your kids. He points out that any time you spend with your kids is quality. Perhaps I'll take this to heart and take my kids for a walk in the woods instead of raking up the woods.

[tags]autumn, chores, leaf+blower, leaves, new+england, new+hampshire, raking, work, yankee[/tags]

I had the pleasure of presenting at DrupalCon in Szeged Hungary, and the topic of my presentation was Drupal security from the perspective of the application. I am pleased to be able to share the video of my presentation. Drupal, DrupalCon, CommonPlaces, Szeged, security, hacking, filters, output

On my latest project, I was faced with a challenge: build Flash widgets that displayed dynamic data and could be embedded on any web page. Phase two of the widgets called for user interaction with the widget, as opposed to simply displaying content. It seemed that Flex would be the most logical technology to use for this project.

I used the Services and AMFPHP modules for Drupal to expose content via web services for my Flex widget to consume. However, I ran into a problem with the critical piece that Flex needs in order to get remote data. As a workaround to the browser security settings that prevent cross-site scripting, Adobe chose to implement an opt-in solution in the form of a file called crossdomain.xml. With crossdomain.xml, a site owner may allow a list of domains to read its data and the client, Flash in this case, is responsible for enforcement. As the business case for the project called for the widget to be embedded on any domain, I needed to use a promiscuous crossdomain policy, allowing access from all domains:

[xml]

[/xml]

Because of this policy, the widget was allowed to read all data on the site that the user has access to, including any (authenticated) content and (session) cookies. This could easily lead to privacy violations, account takeovers, theft of sensitive data, and bypassing of CSRF protections.

Other domains in a similar predicament have simply hosted their APIs on a different domain, thus preventing access to user data on the root domain. Unfortunately, the nature of Drupal doesn't allow for splitting the Services functionality out from the rest of the platform.

My solution was to write a forwarder, which is just a really simple PHP script, that is hosted on a subdomain. This subdomain hosts the promiscuous crossdomain policy, and the policy file on the root domain is configured to only accept requests from the subdomain. The forwarder does two things: it first makes sure that only requests to /services/amfphp are allowed; if allowed, the $HTTP_RAW_POST_DATA is sent to the root domain via cURL.

Because the subdomain doesn't host any data at all, the security risk has been removed. If you are working with Drupal and Flash remoting, you'll need to consider the risks associated with promiscuous crossdomain policy files. While my solution certainly isn't the only solution, it is pretty effective and simple.

[tags]Adobe, crossdomain.xml, curl, Drupal, Flash, Flex, forwarder, policy, security, vulnerability, widget, xml[/tags]

Drupal is incredibly flexible, but in current versions, lacks the ability to export content easily in the form of widgets. However, the Services module gives you that flexibility in a very easy to use manner.

Services allows you to expose pieces of your Drupal site, such as user, node, and views methods. Combine this with the integration of AMFPHP, you can build some extremely fast Flash and Flex widgets that display dynamic data and can be embedded on any website.

However, there is a catch.

I was working with another developer on a Facebook application that displayed my Flex widget, and it seems that in Facebook, you have to provide a static image for the user to click on in order to active the flash. This is clunky, and not the ideal solution for me.

Another option was to attempt to create cross-domain javascript widgets. I looked at JSON Server, which is a Services wrapper that returns data in JSON. This module worked great on the same domain, but failed on cross-domain calls. The reason why is that the module only accepts POST requests.

I ended up patching the module to accept GET requests structured in the following manner:

[js]
function get(){
headElement = document.getElementsByTagName("head").item(0);
var script = document.createElement("script");
script.setAttribute("type", "text/javascript");
// The callback parameter is needed so that the JSON gets returned correctly in order to be handled by the output function
script.setAttribute("src","http://server.com/services/json?method=views.getView&view_name=some_view&callback=display");
headElement.appendChild(script);
}

function display(obj){
var theDiv = document.createElement("div");
theDiv.innerHTML = obj.data;
document.body.appendChild(theDiv);
}
[/js]

You'll note that I am doing script tag inserts into the head of the calling website. The script source is set to the path of my JSON server, with the services method as a parameter. The services method takes arguments, which differ depending on the service you are calling. In the case of the Views.getView service, you have to supply the name of the view to call.

The last parameter specifies the name of your output function. My patch takes this callback and wraps the JSON-formatted data returned by the service with the name of the callback. The callback is extremely important, as the JSON sent back by the server acts as a call to your defined callback function. From there, your callback function can display the data however it chooses.

Implementation of this method on a remote site is very easy:

[js]

get();
[/js]

For my widget, I created a custom service that returned the output of a theme() function to render the widget template. This html output was then displayed by my JSON callback function.

Using the Services and (patched) JSON Server modules for Drupal, you can quite easily set up cross-domain javascript/html widgets that can be embedded anywhere.

[tags]callback, cross-domain, Drupal, flash, flex, javascript, JSON, scripting, Services, widgets[/tags]