drupal administration

This week we roll out the first batch of videos in our "Advanced Site Building for Drupal 7" collection. These videos address the growing importance of the 'site builder' in Drupal site development, what administration tools can help speed up the building process, and how we can quickly set up a prototype site on our local machine. There will be more to come, but if these videos don't get you excited about the power of site building, then ... well, try watching them again on double-speed.

Welcome to "Advanced Site Building"

In this video, we give a quick introduction to the new video series and describe the set of modules we'll be covering, including Panels, Display Suite, Views, Feeds, a slew of administrative tools and more.

About our project and how project roles work

In this video series we build a practical Drupal site for a company called GiftOfGeek, one of those businesses we all wish we worked at that specializes in geeky products like USB-powered phosphorescent Zen gardens. We also take a look at how tasks are typically split across a web team.

What a "site builder" is and the powerful tools they work with

Throughout this series, we'll be focusing on the role of 'site builder'. In this video we explain where that role begins and ends, and the kinds of tools they use to get their work done.

What wireframes are and where to find them in our resource pack

If you talk to anyone who's had to work with clients to build a web site, they'll tell you how dangerous it is to start with a design. Instead, if you distill the major informational components into a black and white 'wireframe', you give the client a sense of what goes where, without issues like colors and padding getting in the way. In this series we begin with some wireframes, and this video shows you where to find them.

Identifying the components in our blog home page wireframe

The first wireframe we look at is our blog home page. Although it's unassuming and seemingly fairly simple, it touches on a number of techniques and Drupal modules that we'll have to understand in order to make it happen. In this video we discuss the various components of the page briefly and link them up with the modules that will help us build it.

Reviewing our blog post and review page wireframes

Our client site is focusing on two major features: a blog and product reviews, and now that we're hopefully getting into our wireframe groove, we wrap up by looking at our blog post and review page wireframes. These wireframes will set a good foundation for us to explore some different ways of laying out content as we work through this series.

About our step-by-step approach

Thinking about our project in terms of modules and tasks can get overwhelming. We're instead going to take a do-one-thing-at-a-time approach that works well in the real world as long as you don't have too many site building coworkers working on the same project. In this video we talk about that approach.

How to set up our Drupal installation with Acquia Dev Desktop

In previous videos we've talked about installing a default Drupal site with Acquia Dev Desktop, but we're also not ones for skipping steps. So in this video we set up our Drupal site exactly the way you're going to see it for the rest of the series.

About the administration modules we'll be using

Before we start building out our site, we're going to install a few modules to help make the building faster and easier. In this video we briefly talk about the modules we'll be installing and why.

How to install a module the traditional way and configure the Administration Menu module

Throughout this series, we're going to be installing a lot of modules. If you're new to Drupal, we're going to illustrate in this video the traditional way to install a module by downloading it and moving it to your module folder. But there's better ways, and we'll be talking about those next. In this video we also configure the Administration menu to replace our existing top-of-the-page menu with a slick drop-down.

How to install a module using Drush, and how we approach installing modules in this series

It's okay to be afraid of the command line, but at BuildAModule we've put together a series of videos that should help you get over that fear. The payoff is that you get to use Drush to speed up many time consuming tasks like installing modules. In this video we show you how you can shave a minute or so off of each module installation, and a bit about how to make sure Drush works properly with our Acquia Dev Desktop installation. From here on out, whenever we install a module, we're going to flash a screen up with information about the module so you can choose whatever method you're comfortable with to install it.



200908131139.jpgIt recently came to my attention that there are some gaps in my conceptualization of Drupal security. I was fortunate enough to have this pointed out to me by the Drupal Security Team, and not by a DOS, CSFR, SQL injection or XSS attack. After publicly bemoaning the mild lashing I received, four members of the Drupal community suggested I read Cracking Drupal. One of them even sent me a copy. No other book was even mentioned, which says to me that - considering how recently it was released - the book fills a void of knowledge that was seriously aching for coverage, and fills it well.

Over years of developing, I've become familiar with the various vulnerabilities that make their way into code, but I've never felt like I could build a complete defense. My knowledge has been piecemeal, drawing from documentation, books, interesting conversations and other people's code. In my case, Cracking Drupal did a fantastic job of gluing these pieces together into a comprehensive frame of mind.

What becomes clear very quickly in Cracking Drupal is that Drupal is quite a wily beast that gives developers real incentive to learn security. There are few functions in Drupal whose exclusive purpose is security, and Greg makes it clear that learning how to secure your site has definite side benefits: "When developers learn and use the API, they are not only safer but more effective and more efficient." When you learn how to use different aspects of the Drupal API (forms, translations, helper functions, theming) you gain bits of security as a bonus. If you set out to learn Drupal security, you'll come out the other end with a pretty solid grasp of Drupal APIs. Either way, it's a win.

Cracking Drupal is surprisingly brief. In 134 pages, Greg covers a lot of ground including:

  • An overview of the different types of attacks one is likely to encounter, from physical to social
  • Most (if not all) aspects of the Drupal API that have security implications
  • Coverage of security-related contributed modules
  • An introduction to the Drupal Security Team
  • Demonstrations of exploiting common weaknesses in Drupal modules and how to fix them

An interesting choice is made in Cracking Drupal to keep a somber atmosphere around the subject matter. In almost any other context, this would be an immediate turn-off. I appreciate humor and optimism to drive my enthusiasm when reading. In contrast with other instructional books which end a chapter with a "go for it, get things done!" message, this book ends chapters with lines like "This paranoid perspective is a good one to maintain as you write, review, and implement features on your site." and "Remember that it is nearly impossible to fully protect yourself from a dedicated and persistent attack." and "If nothing else, I hope this chapter has scared you a bit about the realities of just how easy it is to exploit insecure code and sites".

In a book covering attacks that can result in a very serious loss of time and money, this lack of optimism is probably a good thing. And the final chapter, "Un-cracking Drupal" does leave the reader with the sense that something can be done. It's difficult work, but it's doable. Ultimately, I think the book drives home the fact that the most effective way to make a module or theme secure is to do it right from the start.

The title chapter of Cracking Drupal was probably the most lively and hands-on part of the book. I came out of it feeling like I could really enjoy exploiting vulnerabilities for the greater good. Because of this reaction, I think it would have been a good candidate for a first chapter to really whet people's appetites.

Overall, I think Cracking Drupal does a tremendous service to the community by pulling together the most important aspects of Drupal Security into one solid, compact document. While I came into the book having already been introduced to many of the concepts, it filled in a few gaps, and made the subject matter finite and approachable (albeit a little scary). I suspect this book will serve well as a guide and quick reference as I dive into identifying and patching up vulnerabilities in the modules I maintain.

A couple things I learned

While the greatest benefit to this book was the broad, sweeping overview of security, there were a few additional gems that will come in handy later on:

  • There's a lot more to hook_menu() than I was aware of. Good coverage of examples on p.55
  • I didn't realize that you had to exit after using drupal_access_denied(). p.59
  • Ah, db_placeholders() - a useful function for passing a number of variables to db_query() p.65
  • I had no idea there was such a robust node access API. Wow!

Notes in the margin

Below are a few unorganized comments that constitute my wish-list for future versions and complements to the author:

  • Good quote regarding the definition of security: "For this book I’ll define site security as follows: A site is secure if private data is kept private, the site cannot be forced offline or into a degraded mode by a remote visitor, the site resources are used only for their intended purposes, and the site content can be edited only by appropriate users."
  • I would have liked to see more AJAX security strategies and techniques covered.
  • I liked all the Drupal 7 references, gives a good feel as to the direction of things
  • I was surprised that there were not more brutal admonitions about hacking core, but suspect that's because they represent much fewer vulnerabilities than badly designed contrib.
  • I was happy to see some coverage of CVS and DRUSH, namely using CVS to keep code up-to-date
  • Nice coverage of security-related modules starting around p.41
  • A brief mention is made that using mixed-mode SSL is pretty pointless. This is a big deal, I wish it had gotten further coverage.
  • Being more of an optimist, I appreciated this particular phrase: " Every day there are more and more techniques beingdeveloped to attack sites, but every day there are also Drupal users reviewing code and providing new modules and enhancements to core to keep your site safe." Ahh, a glimmer of hope!
  • Would have liked to see more coverage on the use of form tokens. If one must step outside of the forms api, this could be very important
  • I liked that theme safety was covered, and thought the take on it was interesting: Make the theme secure by giving themers no reason to make stupid mistakes.
  • Since the 'Vulnerable' module was patched up in the end, maybe it should actually be named to indicate that it's meant to be a useful module. That would feel more like a practical example.



I had short, but interesting dialog with sun on groups.drupal.org regarding how to go about getting a better menu interface into core. Sun maintains the Administrator Menu project and it sounds like the module might be earmarked for core inclusion in Drupal 7. The discussion got me thinking about what it would take to unify the efforts of module creators and maintainers and develop really solid api and tool set for getting around in Drupal. I maintain the Navigate module, which is a proof of concept for the kinds of tools I'd like to see, and I've been trying to decide if I should continue improving the module, or see if I can combine efforts with other like-minded folks in the community to can get something good enough for core.

Leisa, the usability professional working with Mark Boulton on the new Drupal 7 design, mentioned that what Drupal really needs is a genuine interfacelift (get it, interface + facelift? </whimsy>), not just small incremental changes. To this end, they set up a booth at Drupalcon soliciting ideas for improving Drupal's administration system, and have recently posted the videos. This 'facelift' might be a perfect opportunity for getting the infrastructure required for new - more usable - tools into core.

It's premature for me to assume that this kind of effort would be welcomed in the community or that I will have the resources to head up the process, but - at least in my head - it seems like it could have a much more lasting impact than releasing an updated version of a single administration module among many.



Syndicate content