I just wanted to share a couple new techniques I’ve learned:

The first is pretty simple - Apple’s mod_auth_apple supports authentication against local accounts. This means there’s no need to maintain a separate .htpasswd list. You can just create a .htgroups file with groups defined as:

groupname: user1 user2…

where the users are usernames for local accounts (note the that account password type can be either shadow or OpenDirectory). The .htaccess configuration is the same as if you were using mod_auth:

AuthName “My Protected Area”
AuthType Basic
AuthGroupFile /path/to/.htgroups
Require group groupname

The second trick I’ve learned deals with the interaction between mod_auth (or mod_auth_apple), mod_rewrite, and SSL. You can use mod_rewrite to force a directory to use SSL by adding something like this to the .htaccess file:

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=permanent,L]

This rewrites all non-SSL connections to SSL connections; it’s more user-friendly than SSLRequireSSL, which just displays an error for non-SSL connections. However, problems arise when the directory is also protected with mod_auth. The authentication directives are read before the rewrite directives, so the user is prompted to authenticate over a non-SSL connection. Then the rewrites kick in, and rewrites to a SSL connection. Mod_auth sees that the URL has changed, and prompts to user for authentication again. So, what the user sees is one unsecure prompt, followed by a second secure prompt. This is both a security risk and confusing to the user.

The solution I’ve found is to put the rewrite rules in a .htaccess file in the target directory, but to put the authentication rules in the virtual host configuration for port 443 only. This way, when the user attempts a non-SSL connection, there are no authentication rules in place, and the rewrite happens immediately. Once the URL has been rewritten to SSL (and thus to port 443), Apache now sees that that are authentication rules in place and prompts the user to supply a username and password over a secure connection.

This solution could be cleaner if there were an Apache directive similar to that would allow you to discriminate by port number - if this were available, the entire configuration could go in a .htaccess file. As it is now, you have to configure two virtual hosts for each site, one on port 80 and one on port 443. OS X configures sites this way by default, but other for other servers this fix might require more work.

Third time’s a charm! (let’s hope)

I upgraded WordPress to version 2.0.3 from 1.5. This was my third attempt at upgrading. My previous two attempts were unsuccessful in that the blog seemed to perform much slower after upgrading.

This time around, I took all the precautions: backing up data, deactivating plugins, etc.

One by one, I will start upgrading and reactivating some plugins to get everything back to speed (ex. Archives plug-in). I also need to recode some hacks (ex. users can edit own comments).

I’ve written previously about wp2.0 after my 1st upgrade attempt. Read about it here

[NOTE]
The oceaninformatics.ucsd.edu/blog url is an alias oceaninformatics.ucsd.edu/index.php?cat=12

[UPDATE]
All plug-ins and hacks are back up. Enjoy!

Last year, members from various LTER sites collaborated in creating the LTER EML Unit Registry. This made possible having an authorative source of units for reference in generating EML documents.

Though the Unit Registry effort has been successful, there have been a few technical drawbacks. One issue was dealing with “junk” characters in the unit abbreviation field. This is the result of different character encoding types conflicting with each other.

For example, the unit metersPerSquareSecond should have an abbreviation m/s². However, the LTER EML Unit Registry page is using a charset encoding of iso-8859-1. This encoding type causes the “junk” characters to appear. The picture below shows the source code from the LTER EML Unit Registry home page.

To solve this issue locally, I set the charset encoding type to UTF-8. This Unicode standard ensures that the correct characters appear…. among these are the superscript 2 and 3 (for squared and cubed respectively), and the greek letters Mu (for micro) and Omega (for ohm). The picture below shows the source code from the Ocean Informatics Datazoo home page. The Palmer LTER and CCE LTER Unit Registries are kept in sync with each other.

Notes:
- To remove the junk characters, I copied and pasted “Special Characters…” from the Safari Browser Edit window.
- No changes were required in the MySQL Collation, contrary to initial thought. MySQL is able to store Unicode-encoded strings as text datatypes, using our default Collation of latin1_swedish_ci.
- Unicode-encoded strings should not be wrapped by the htmlentities() function in PHP. This will cause the “junk” characters to appear.
- This page was a good reference for working with Unicode in MySQL and PHP. Additionally, the O’Reilly book Bulding Scalable Web Sites has an entire chapter devoted to character encoding. This book was authored by Cal Henderson of Flickr fame. I was able to read parts of the book at Safari Tech Books Online.

Here’s a link to a very spirited exchange on different versioning tools and methodologies:

http://ask.slashdot.org/article.pl?sid=06/06/05/1922209&threshold=-1

Here’s an intriguing excerpt that talks about SVN and WebDAV:

SVN + WebDAV + Autoversioning
(Score:5, Informative)
by HFShadow (530449) on Monday June 05, @06:20PM (#15475989)
http://svnbook.red-bean.com/nightly/en/svn.webdav. autoversioning.html [red-bean.com]

From the SVN Handbook:
“Because so many operating systems already have integrated WebDAV clients, the use case for this feature borders on fantastical: imagine an office of ordinary users running Microsoft Windows or Mac OS. Each user “mounts” the Subversion repository, which appears to be an ordinary network folder. They use the shared folder as they always do: open files, edit them, save them. Meanwhile, the server is automatically versioning everything. Any administrator (or knowledgeable user) can still use a Subversion client to search history and retrieve older versions of data.”

And here’s the link to the SVN handbook this came from:

http://svnbook.red-bean.com/nightly/en/svn.webdav.autoversioning.html

Worth a look and perhaps a followup discussion.