Thursday Threads: Unprotected Social Media Sites, Value of Free, and Real Life Net Neutrality

Receive DLTJ Thursday Threads by E-mail! Enter your email address:

Delivered by FeedBurner

This week’s Thursday Threads looks at a big hole in the security model of most internet sites that require you to log into them with a username and password plus a pair of stories about “big media” battles. If you find these interesting and useful, you might want to add the Thursday Threads RSS Feed to your feed reader or subscribe to e-mail delivery using the form to the right. If you would like a more raw and immediate version of these types of stories, watch my FriendFeed stream (or subscribe to its feed in your feed reader). Comments, as always, are welcome.

Thursday Threads: Technical Debt, QR Codes in National Parks, WebP Image Format, and SSL Cautions

Week #2 of this new project to highlight interesting tidbits from the previous seven days. Well, things that were interesting to me that I hope will be interesting to DLTJ readers. Time will tell.

SSL for WordPress Admin and the Problem with XMLHttpRequest

Note! The updates to SSL handling in WordPress version 2.6 handle the problem of SSL-encrypted admin sessions in a much less hackish sort of way. It doesn’t make any sense to use this plugin with WordPress version 2.6 when you can simply add define(’FORCE_SSL_ADMIN’, true); to your wp-config.php file.

The WordPress Codex has documentation for running the login, registration, and administration interfaces on an SSL server. There is even a plug-in that will do much of the heavy lifting for you. I have found both of these methods, by themselves, to be rather unsatisfactory, though, in that admin services that rely on AJAX calls back to WordPress break (such as the periodic saving of drafts). What happens is this:

OpenLDAP with a Go Daddy “Turbo SSL Secure Certificate”

Okay — this seemed like a lot harder than it should have been. At the very least, it took piecing together information from a number of places in order to make it happen. The goal is to use a Go Daddy Turbo SSL Secure Certificate (the $19.95/year one) to secure an OpenLDAP server. On the surface, this shouldn’t be so hard. The tricky part comes because the requested SSL cert is not signed by a recognized Certificate Authority root; instead, Go Daddy uses an intermediary certificate and the tricky part is making sure the whole chain of SSL certificates line up properly. There is a wealth of documentation for using intermediary certificates with web servers, but I found very little for OpenLDAP servers. I hope by posting this into the blogosphere you will find it useful someday, too.