Roman’s tech blog

Simple, but nice replacement for open-uri library (which uses rather slow Net::HTTP library) which uses libcurl (via curb).
It’s easy to swap the original one just by replacing ‘require open-uri’ with ‘require curb-openuri’. Should work as the original, even with better defaults (which, of course, can be changed).

http://github.com/romanbsd/curb-openuri/tree

I just wanted to display reCAPTCHA inside a ModalBox.
This simple task turned out to be quite complicated.
After playing with innerHTML, creating <script> nodes manually and attaching them and other voodoo and black magic and failing to accomplish the desired effect, I settled with displaying the recaptcha inside iframe inside ModalBox.

 Modalbox.show('<iframe src="' + this.href + '?iframe=1"></iframe>', 
  {title: this.title, width: 600});

(The iframe parameter helps to select another layout).

There’s a nice plugin which adds helper for the reCAPTCHA. The downside is that it doesn’t support I18n at the moment.
This is a straight forward approach patch that adds this functionality. (I don’t know what will be the fate of I18n in Rails 3, thus the simple check for version).
The error message path then will be:
activerecord.errors.models.model_name.captcha

diff --git a/lib/recaptcha.rb b/lib/recaptcha.rb
index 87c26e9..44413bc 100644
--- a/lib/recaptcha.rb
+++ b/lib/recaptcha.rb
@@ -65,7 +65,11 @@ module Ambethia
             session[:recaptcha_error] = error
             if model = options[:model]
               model.valid?
-              model.errors.add_to_base "Captcha response is incorrect, please try again."
+              if Rails::VERSION::MAJOR >= 2 and Rails::VERSION::MINOR >= 2
+                model.errors.add_to_base I18n.translate("#{model.class.name.underscore}.captcha", :scope => %w(activerecord errors models), :default => "Captcha response is incorrect, please try again.")
+              else
+                model.errors.add_to_base "Captcha response is incorrect, please try again."
+              end
             end
             return false
           else

I wonder if this is the proper way of adding I18n support…
P.S. I reported this on lighthouse.

The following steps are usually sufficient in order to make “pretty URLs” in mediawiki, e.g.

http://wiki.somehost.com/Article_Name

In Apache configuration:

RewriteEngine on
RewriteCond %{REQUEST_URI} !^/(skins|stylesheets|images|config)/
RewriteCond %{REQUEST_URI} !^/(redirect|texvc|index).php
RewriteRule ^(.*)$ /index.php?title=$1 [L,QSA]

In LocalSettings.php

$wgScriptPath       = "";
$wgScript           = "$wgScriptPath";
$wgRedirectScript   = "$wgScriptPath/redirect.php";
$wgArticlePath      = "$wgScript/$1";

However, the latest version (1.12.0 at the time of writing) needed the following patch, in order to make all things work. I don’t know whenever this was already reported by someone and/or fixed.

--- includes/Title.php.orig     2008-08-05 22:56:32.000000000 +0300
+++ includes/Title.php  2008-08-05 23:16:22.000000000 +0300
@@ -832,7 +832,12 @@
                                        if ( $query == '-' ) {
                                                $query = '';
                                        }
-                                       $url = "{$wgScript}?title={$dbkey}&{$query}";
+                                       # Assume "pretty URLs" if wgScript is empty
+                                       if ( $wgScript == '' ) {
+                                               $url = "/{$dbkey}?{$query}";
+                                       } else {
+                                               $url = "{$wgScript}?title={$dbkey}&{$query}";
+                                       }
                                }
                        }

This upgrade was a real pain.
Though there are many resources on the web, which talk about this kind of upgrade (and the best one in my opinion is this one: http://julien.danjou.info/blog/index.php/post/2008/05/19/Upgrading-mediawiki-from-PostgreSQL-82-to-83), all of them fall short of giving a succinct but precise instruction for this upgrade. I tried to follow the aforementioned article, but it still gave some errors.
So I’ve done something similar, but a little bit different, finally importing the 8.2 database without a single error.
First of all, I dumped the original database in two parts – schema and data.
I took the schema part and divided it in two: schema definition and constraints and indexes. From the former I removed all references to tsearch2 functions, in the latter checked that the “search_path” is correct for every bulk of updates. Then I wanted to import the new tsearch2 functions that come with PostgreSQL 8.3.
So I wrote a simple script which I used in order to import the db several times, fixing bugs and eliminated all the problems which were still present:

#!/bin/sh
export PGUSER=postgres
dropdb wikidb
createdb wikidb
psql -q wikidb < /usr/share/pgsql/contrib/tsearch2.sql
echo "Inserting wiki schema"
psql -q wikidb < wiki_schema.sql
echo "Inserting data"
psql -q wikidb < wiki_data.sql
echo "Inserting constraints"
psql -q wikidb < wiki_schema_constraints.sql

At the end all files were imported without a single error.
Then I discovered, that I’ll have to update mediawiki from 1.11.0 to 1.12.0, since the former doesn’t work with PostgreSQL 8.3
The update had only one problem (missing file – it’s mentioned in the link above), which was easy to remedy.
Upon using the mediawiki I found out, that I’ve to grant access to one of the tables.
It was probably due to the fact, that it was added to schema by user other than wikiuser:

GRANT ALL ON TABLE protected_titles TO wikiuser;

Seems to work fine so far.

When trying to help our engineers to configure Apache 2.2 I found out to my complete astonishment, that Apache doesn’t allow negation of environment, e.g. to perform some action in context of mod_authz_host allow/deny when some environment variable DOESN’T exist, thus the directive below has no effect:

Deny from env=!HAS_SOMEVAR

I opened a bug with a patch, which was accepted, and lately it was backported to 2.2 branch, therefore it will appear in the next version (2.2.10).

Other shortcoming that I’ve found, that it’s impossible to unset a cookie while using mod_rewrite, but checking the code revealed, that the value for the cookie isn’t checked, therefore it’s possible to inject arbitrary string there, and this is exactly what I did:

RewriteRule ^/$ http://myhost.domain/url [CO=JSESSIONID:;comment=Reset:.myhost.domain:0:/,L]

Notice the trick – the value for cookie is “;comment=Reset” and validity period of 0 minutes making the Set-Cookie header look like this:

Set-Cookie: JSESSIONID=;comment=Reset; path=/; domain=.myhost.domain;
  expires=Sun, 27-Jul-2008 12:00:08 GMT

The dhtmlxTabbar is a nice tab-bar component from http://www.dhtmlx.com/
In order to use the AJAX loading feature I had to make a small change in the dhtmlxcommon.js so it mimics the behavior of Prototype by adding a X-Requested-With HTTP header. Thus, it’s possible to use request.xhr? in Rails.
dhtmlxcommon.js

Today was a perfect day for hacking wget.
I wanted to mirror some site, and to my astonishment found out, that wget doesn’t support regular expressions for including the paths to mirror. Only a list of directories for including/excluding could be provided.
This was easily remedied using the excellent pcre library.
The patch is quick and dirty, and if one would like to compile wget with it, -lpcre should be added to LIBS in Makefile.
Patch for wget which adds regular expression matching for urls

Update: Well, it seems that there was a similar patch available for years: http://www.mail-archive.com/wget@sunsite.dk/msg07395.html