WordPress Upload HTTP Error Fix

Several versions of WordPress ago, I started sporadically encountering a problem while trying to use the Flash uploader in WordPress. Every time I tried to upload something using the Flash uploader, I would just get this HTTP Error message:

A Screenshot of the HTTP Error message when attempting to upload a files in WordPress

I searched for a solution to the problem and found that it was a bug in one of the older versions of WordPress. Now, several versions later, it’s still happening. I’ve seen it on both WordPress 2.7 and WordPress 2.8. More Googling revealed several tips about about adding directives to the .htaccess file. I tried each of them, but with no success.

The most puzzling part of this problem for me was that I have several different installations of WordPress on different servers and different versions, but this error was only happening on some of them. After I actually sat down and thought about the problem, I realized that the error was only occurring on the WordPress installations that I had set to be private through the authorization control using my .htaccess files. Those sites have an .htaccess file in the root directory which starts with something like this:

AuthName "private site"
AuthType Basic
AuthUserFile /home/private/.htpasswd
Require valid-user

This causes a dialog box to pop up when you try to go to the site. You have to specify a correct username and password, as specified in the .htpasswd file, in order to gain access to the site.

After realizing there might be a connection with this, I tested using the flash uploader on one of my sites with the htaccess authentication turned off. Sure enough, it worked like a charm. So after realizing that the HTTP Error was definitely related to this, a solution was easier to find.

The solution that worked for me was to create an .htaccess file in the wp-admin directory. The htaccess file should have the following rules in it:

AuthType Basic
AuthName share
Satisfy Any
Order deny,allow
Allow from all

<IfModule mod_security.c>
<Files async-upload.php>
SecFilterEngine Off
SecFilterScanPOST Off
</Files>
</IfModule>

Since adding this file, I’ve been using the image uploader on my protected sites without a problem.

Destroy Kerberos Ticket

Since we deployed Leopard to the computers labs at work, I’ve been running in to this annoying problem involving Kerberos. I hadn’t spent any time trying to figure out how to circumvent it until now because it really only affects administrators. We can deal with our own problems right?

When a user logs in, they authenticate to our server using their account username (use Alice for this example). At this point they are given a Kerberos ticket. From then on, in Leopard, whenever the user attempts to connect to an AFP share on the server, Leopard assumes that they are connecting as the same user, Alice. Because the Kerberos ticket is still valid, the user is automatically authenticated as Alice. Of course, this makes perfect sense. That’s the whole point of Kerberos: single sign-on.

The problem resides in the assumption that the user wants to connect as the same user every time. What if Alice is actually an admin who needs to log on to a share using different credentials? Here’s an example: I’m testing a student account, with normal student privileges. During the course of my testing, I need to access a document from our administrative share point. Now, obviously the student account does not have access to the administrative share point. I would need to log in to the share using a user with permissions to access the administrative share point.

Unfortunately, Leopard will not even ask me what user account I want to use because I already have a valid Kerberos ticket for the student account. Fortunately, after finally getting fed up with this problem, a quick bit of googling solved it.

All that needs to be done is to destroy the Kerberos ticket. Simply open Keychain Access and select Kerberos Ticket Viewer from the Keychain Access menu. Select your Kerberos ticket from the window and click the destroy button. This doesn’t actually harm anything, it simply makes your Kerberos ticket expire. The next time you try and connect to the server, you will be asked to authenticate again; at which point you can authenticate as a different user.

Alternately, you could also create a new Kerberos ticket using a separate username to the same server. The before authenticating to a share, you would simply change the active user. Unfortunately it seems as though you can only access one at a time. For example, I could not mount two different user’s home directories at the same time. I would have to activate a user, mount their home directory, eject it, activate the second user, and then mount their home directory. Hmm, as you can probably see, there doesn’t really seem to be a reason why this would be useful. Probably simply destroying the ticket is the best bet.

For more information on this, check out the Mac OS X 10.5: About Kerberos in Mac OS X 10.5 clients knowledge base article from Apple.



appointive
appointive
appointive
appointive