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:

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.

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.

I stumbled across this great tip the other day about solving that pesky error message that happens when you try and eject a that is busy disk. This seems to happen all too often, I’ll try and eject one of my external hard drives and get the message even though there are no visible programs using it. Sigh. Use this commmand in Terminal:

lsof | grep DISKNAME

Read the full tip from Mac OS X Hints.

There is a command for Terminal in OS X which allows you to take screenshots from the command line. Creepy creepy. Here is the format:

screencapture -x FileToSaveAs

The -x option tells it not to make the shutter click sound. There is also an -i option which triggers an interactive mode, although I’m not sure why you would use the Terminal to do that.

There is also a cute little tidbit in the man page for screencapture:

Yesterday I blogged about the nifty little Open in Firefox script that I made. As it turns out, there is an even better way to this, using some fancy Quicksilver magic.

• Another Quicksilver Tutorial: Gold Trigger

By using Proxy Objects in Quicksilver, you can gain access to the Current Web Page object. After making sure that you have activated the Open URL With... action in the Quicksilver preferences you are free to specify Firefox (or another browser).

Current Web Page → Open URL With... → Firefox

Once you have this working, you can set it up as a custom trigger. I set mine to the F1 key. Even better, this trigger is much more extendable than the script. You might not necessarily always want to open a URL in Firefox. Say you want to open a page in Opera. Just create another trigger, but leave out the item in the third pane.

Current Web Page → Open URL With... → "Leave this blank"

Now when you use that trigger, activate it with a hotkey (I used F2) and type in the first few letters of the browser (or program) you want the URL to open in.