Picasa Album Uploader 0.5 released

Many thanks to go out to WordPress user rbredow for the assistance in isolating an interaction problem affecting some users of the plugin.  Sites that have a PHP hardening plugin called Suhosin configured might experience a  problem in attempting to upload files.  After Picasa displays the upload dialog and you press the upload button, The Suhosin plugin might strip out the uploaded files from the request stream.  This results in seeing a result page that Picasa failed to upload any files.

If Suhosin is configured, you might see an error like the following in the server error log:
ALERT - configured request variable name length limit exceeded - dropped variable 'http://localhost:51134/b921a58ec2806ab82f5399515fba226e/image/b0f008e85a4fa153_jpg?size=1024'
The fix is pretty simple. Check the Suhosin setting values for `suhosin.post.max_name_length` and `suhosin.request.max_varname_length`.  A setting of at least 100 is recommended to allow the long variable names that are required by the Picasa engine.  You might need to increase it further depending on the length of the dropped variable name observed in the error log.

One word of caution, in the last few months Google has deprecated the Picasa application APIs used by this plugin and has offered no replacement. At this point what it means is that the code in Picasa allowing buttons to be configured is unsupported and it might fail or be removed from a future release of Picasa.

The 0.5 release documents this interaction and also fixes some error reporting when uploads fail due to file system protection problems.  Plus I’ve added i18n support so if someone wants to submit a translation, I’m happy to include it.

Thanks for using this plugin!

Picasa Album Uploader v0.4 Released!

It’s finally out.  After a number of fits and starts there’s a new version of the uploader available that has two key features.

  1. Requires Permalinks be enabled.
  2. Enhances error reporting and debugging messages

Additional debugging is turned on from the Admin -> Media settings screen.  Picasa is very picky about how things work and has very poor error reporting making it difficult to determine what has gone wrong.  The additional debugging should help me isolate problems when they are reported.

To download the latest version, visit the plugin home page:

I have not had the time to download and test with WordPress v3.o.  If you do give it a try, please let me know how it goes!

Picasa Album Uploader 0.4 coming soon

I’ve been making slow progress on some updates to the Picasa Album uploader.  After a fair amount of trial and error I’ve come to the conclusion that at least for right now the use of permalinks in the site configuration is required for the plugin to function with the Picasa Desktop.  The Picasa Desktop application is very picky in terms of the URLs that it will accept during the exchange and fails to perform the necessary processing to include images in the POST request when strict rules are not followed.

The big change coming in 0.4 is the addition of some improved error logging so that trouble shooting of failures is a bit easier.  This version is also going to require that permalinks are enabled for the plugin to operate.

Picasa Album Uploader Beta v0.3 Released!

Today marks the first release to the wild of a WordPress plugin I’ve been working on called Picasa Album Uploader.

We use Picasa Desktop to manage our photos and I’ve been wanting an easy way to publish photos from Picasa to WordPress Sites we have.  The other examples that exist for WordPress require files to be placed in the wp-admin directory which just didn’t sit well with me.  Starting with those examples I created a new plugin that is a true WordPress plugin and does not require any files in wp-admin or the server root.  I hope people find it useful!

To discuss or report problems with the plugin visit the WordPress.org Plugin and Hacks Forum.

File Uploads and Mod_security vs. WordPress wp-admin/admin-ajax.php

After having a site hacked because mod_security was disabled I’ve been in search of a better way to allow WordPress to work and still have mod_security running. There are many places that recommend placing the following code in your site .htaccess file:
<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off

DO NOT DO THIS! Else you’ll likely fall victim to the same SQL Insertion hack I did that allowed the infiltrator to directly change elements of my database and redirect the site. Thankfully the damage was very minor, limited to a few WordPress configuration changes that were easily undone. It could have been much, much worse.

In my case, there were two separate issues to contend with as exhibited in the Apache server error log.

Case 1: Patern Match

You will see a line in the server error log that contains text similar to:

mod_security: Access denied with code 403. Pattern match "!(^application/x-www-form-urlencoded$|^multipart/form-data;)" [severity "EMERGENCY"] [hostname "hostname"] [uri "/wp-admin/admin

In some cases the code might be other than 403 and the quoted pattern might be different. Note that the uri field will point to the location of the admin-ajax.php script in your install. There are several options to correct this false positive without completely disabling mod_security.

  • Fix the mod_security rule that defines the pattern.

    There are a number of references that indicate the mod_security rule is incorrect. A good summary can be found at The Team Extreme Blog. What it all boils down to is improper matching of the content type application/x-www-form-urlencoded. The suggested rule requires that the content type match exactly. In at least one failing case, this string has been observed to have the value application/x-www-form-urlencoded; UTF-character8. A possible solution is to remove the “$” at the end of the related phrase in the filter rule. For example, it should read:
    SecFilterSelective HTTP_Content-Type "!(^$|^application/x-www-form-urlencoded|^multipart/form-data;)"
    Another option would be to add the offending string to the Filter rule, for example:
    SecFilterSelective HTTP_Content-Type "!(^$|^application/x-www-form-urlencoded$|^application/x-www-form-urlencoded; UTF-character8$|^multipart/form-data;)"

  • Add wp-admin/admin-ajax.php to mod_security white list

    My host provider made this change to the mod_security rules so I can’t report on the specific changes they made. The blog No Logo Required has some whitelisting instructions. I’ve not tried this myself so I can’t confirm the instructions.

  • Disable mod_security filter ONLY for admin-ajax.php

    This might work:
    <IfModule mod_security.c>
    <Files admin-ajax.php>
    SecFilterInheritance Off

Case 2: Error processing request body

Once I had the filter issue resolved, I was getting a new log entry containing the following:
mod_security: Access
denied with code 403. Error processing request body: Multipart: final boundary m
issing [severity "EMERGENCY"] [hostname "hostname"] [uri "/wp-admin/admin

It seems that some (all?) versions of the flash player send a poorly formatted message body that gets tripped up on mod_security rules. The javascript library in WordPress that handles the image uploads is SWFupload and it requires Flash to operate. The reliance on Flash is creating other problems as well. At least for now, it looks like the solutions are limited as there is no clear ajax based replacement for SWFupload in WordPress.

Some searching exposed the solution in an article at Intersice Solutions. Based on that information and a check on the modsecurity.org site, I placed the following in the .htaccess file in my wp-admin directory:
<IfModule mod_security.c>
SetEnvIfNoCase Content-Type "^multipart/form-data;" "MODSEC_NOPOSTBUFFERING=Do n
ot buffer file uploads"