One source of duplicate comments for Movable Type is users hitting the “POST” button multiple times, either through a key bounce or because of slow response. One amelorative option is to arrange for the “POST” button to be disabled before the comment data is submitted. This not only avoids duplicates in most situations but is useful feedback to the user that, yes, they did in fact push the button.
This turns out to be a bit trickier than it seems, because some browsers won’t send data from disabled objects. This is a problem because the “POST” button contains critical information needed to process the comment request. It is not sufficient to simply move that to a hidden object, because that will cause problems for “PREVIEW”. My solution is to have a hidden object and engage in a bit of object renaming during the disable process. I have tested this on IE 6, IE 7, FireFox 1.5, FireFox 2, Opera 8 and Opera 9, and it seems to work.
This is the JavaScript enhanced “POST” button and hidden object. It replaces the existing “POST” button.
<input type="hidden" name="mode" value="mode" />
<input type="submit" name="post_comment" id="post_comment" value=" POST "
onclick="document.comments_form.post_comment.disabled=true;
document.comments_form.mode.name = 'post';
document.comments_form.onsubmit();
document.comments_form.submit();"
/>The Javascript disables the button, renames the “mode” object to “post” to put that as data in the submit, executes any other JavaScript expected to run on submit, and finally submits the form.
You will need to modify every template that accepts user comments. This will generally be the individual archive template and the preview comment template. It may also be the comment error tempate and the comment popup template.
You will need to modify the name of the FORM tag for comment submission. By default it is named “form” and this can cause hard to diagnose name collision problems. The actual name doesn’t matter, it is just important that it is unique. Use all lower case letters and underscores, nothing else. As you can see above, I renamed mine “comments_form”. I recommend doing the same unless you have a specific reason to use something else. When changing the name, change both the name and id tag and give them the same value1.
Once you’ve renamed the form, replace the current “POST” button with the lines quoted above. Change any instances of “comments_form” with the name you used for the FORM tag if that is different.
name attribute for the “POST” button must not be “post” as it is in the default template.id attribute value for the “POST” button should be the same as the name attribute value.id attribute value and the name attribute value for the FORM tag should be identical. This must also match the name following “document” in the JavaScript.value attribute of the “POST” button to whatever you like — it has no effect on submitting comments, it is used only as the displayed text in the button.1 This is because some browsers like the name attribute and some like the id attribute. There’s no good reason to not do both except for the extra typing.
The trackback API for Movable Type starting with version 3.2 uses the internal numeric ID of the trackback object as the key. This has two problems:
This was unavoidable in previous versions of Movable Type, but with the release of 3.2 and its use of globally unique “basenames” for entries, we can do better.
This modification changes the trackback API to use identifying strings instead of numerics as the trackback key. The trackback object identifiers become completely internal (as was done for entry identifiers in 3.2). This overcomes both of the issues listed above.
This project is deployed on multiple several production weblogs, including this one. You can test it out by doing a trackback to this entry using the URL in the “Trackback URL” link below, or using the URL for this entry with “/ping” appended. Please put text that indicates a test if you do test it, so I can clean those out.
NB: This modification explicitly forbids the use of numeric trackback ids. If installed and followed with a complete rebuild, this should not affect legitimate weblogs as the trackback URLs are pulled from your webpages, which will have the new, correct trackback URLs in it.
This patch is for the 3.3 release of Movable Type. There is a separate patch for version 3.2.
Two files in the base distribution must be modified. You can pick up the modified versions of the 3.32 files here or, if you’re paranoid like me, you can do the modifications yourself. Once the files have been modified, you will need to a full rebuild to update all of the trackback URLs. At that point the modified trackback API should be fully operational.
The lib/MT/App/Trackback.pm file must be modified. Note that there are two files named Trackback.pm in the distribution, be sure to edit the correct one.
Replace the subroutine _get_params at line 98 with the following subroutine —
sub _get_tb {
my $app = shift;
my ($tb, $pass); # Trackback object and password to return
my ($key, $name); # local vars for internal computations
my ($entry, $cat); # Target object of trackback.
if (my $pi = $app->path_info) {
$pi =~ s!^/!!; # drop leading slash
my $tbscript = $app->config('TrackbackScript');
$pi =~ s!.*\Q$tbscript\E/!!;
($key, $name, $pass) = split /\//, $pi;
if ($key =~ m/\d+/) {
$app->error($app->translate(
'Numeric trackback IDs are no longer accepted'));
} elsif (lc($key) eq 'entry') {
require MT::Entry;
$name =~ s/\..*$//; # strip any extension
if ($entry = MT::Entry->load({ basename => $name, status => MT::Entry::RELEASE() })) {
$tb = MT::Trackback->load({ entry_id => $entry->id});
$app->error($app->translate(
'No trackbacks for entry with basename [_1]', $name))
if not $tb;
} else {
$app->error($app->translate('No entry with basename [_1]', $name));
}
} elsif ($key =~ m/^cat/i) {
require MT::Category;
if ($cat = MT::Category->load({ label => $name })) {
$tb = MT::Trackback->load({ category_id => $cat->id });
$app->error($app->translate(
'No trackbacks for category with label [_1]', $name))
if not $tb;
} else {
$app->error($app->translate(
'No category with label [_1]', $name));
}
} else {
$app->error($app->translate(
'Invalid trackback target key [_1]', $key));
}
} else {
$app->error($app->translate(
'Track request URL incorrectly formatted.
The trackback target path information was missing'));
}
($tb, $pass, $entry, $cat);
}
In subroutine ping around line 147.
Line 152 — change
my($tb_id, $pass) = $app->_get_params;
return $app->_response(Error =>
$app->translate("Need a TrackBack ID (tb_id)."))
unless $tb_id;
require MT::Trackback;
my $tb = MT::Trackback->load($tb_id)
or return $app->_response(Error =>
$app->translate("Invalid TrackBack ID '[_1]'", $tb_id));
to
my($tb, $pass, $entry, $cat) = $app->_get_tb;
return $app->_response(Error => $app->errstr) unless $tb;
Line 178 — change
my($blog_id, $entry, $cat);
if ($tb->entry_id) {
require MT::Entry;
$entry = MT::Entry->load({ id => $tb->entry_id, status => MT::Entry::RELEASE() });
if (!$entry) {
return $app->_response(Error =>
$app->translate("Invalid TrackBack ID '[_1]'", $tb_id));
}
} elsif ($tb->category_id) {
require MT::Category;
$cat = MT::Category->load($tb->category_id);
}
$blog_id = $tb->blog_id;
to
my $blog_id = $tb->blog_id;
Line 209 — change
no_utf8($tb_id, $title, $excerpt, $url, $blog_name);
to
no_utf8($title, $excerpt, $url, $blog_name);
Line 209 — change
$ping->tb_id($tb_id);
to
$ping->tb_id($tb->id);
Subroutine rss, around line 423.
Line 426 — change
my($tb_id, $pass) = $app->_get_params;
my $tb = MT::Trackback->load($tb_id)
or return $app->_response(Error =>
$app->translate("Invalid TrackBack ID '[_1]'", $tb_id));
to
my ($tb, $pass) = $app->_get_tb;
return $app->_response(Error => $app->errstr) unless $tb;
Subroutine blog around line 465.
Line 423 — change
if (my ($tb_id) = $app->_get_params()) {
require MT::Trackback;
my $tb = MT::Trackback->load($tb_id);
return undef unless $tb;
$app->{_blog} = MT::Blog->load($tb->blog_id) if $tb;
}
to
if (my ($tb) = $app->_get_tb()) {
return undef unless $tb;
$app->{_blog} = MT::Blog->load($tb->blog_id);
}
The file lib/MT/Template/ContextHandlers.pm should be modified. This is not strictly required, but if this is not done then you will have to construct all trackback related data by hand in the templates rather than using the standard tags.
Changes to lib/MT/Template/ContextHandlers.pm
Line 1820 — change
$path . $cfg->TrackbackScript . '/' . $tb->id;
to
$path . $cfg->TrackbackScript . '/entry/' . $e->basename;
Line 1832 — Change
$path .= $cfg->TrackbackScript . '/' . $tb->id;
to
$path .= $cfg->TrackbackScript . '/entry/' . $e->basename;
Line 3381 — change
$path . $cfg->TrackbackScript . '/' . $tb->id;
to
$path . $cfg->TrackbackScript . '/cat/' . $cat->label;
There are several things to keep in mind once this modification is installed.
One of the drivers for this modification was a request for “friendlier” trackback URLs. In particular, the desire was to be able to have other weblogs link via trackback to a post by using the URL of the post with “/ping” appended as the trackback URL. This requires
.htaccess files to enable mod_rewriteAlso note that this works only for individual archives.
To set it up, in the top level directory for the individual archives, place text like the following in a .htaccess file:
RewriteEngine On # Support trackback pings by appending "/ping" to an individual archive URL. RewriteRule /([^/]+)/ping$ /cgi-bin/mt/mt-tb.cgi/entry/$1
You need to make sure that the path “/cgi-bin/mt/mt-tb.cgi/” is correct for your installation. This is easy to find, simply look at your current trackback URL.
In theory, this should be easily extensible to supporting category trackback pings, although I never use categories so I have not experimented on it directly yet. Note that the URL must be of the form “…/cat/…” instead of “…/entry/…” for category trackbacks.
NB: The name logic for trackbacks automatically strips extensions, so that you can use both “my_cool_post” and “my_cool_post.html” as the name for the trackback URL. This was done to support this technique.
One effect of this modification is to make the trackback URLs noticeably longer. This can cause problems with formatting, particularly of popups. What I have done is change explicit display of the trackback URLs to a link with the link text “Trackback URL”. The reader can then either right-click and use the “copy this link” option (available in FireFox, IE and Opera) or use the “friendlier” trackback URLs.
This project originally inspired by a request from Sherwin Techico on the ProNet mailing list
]]>MTTacFeed (MTTF) is a plugin to create feeds from the comments and trackbacks of a Movable Type weblog. “TacFeed” can be read as “Trackbacks and Comment Feed” or “Tactical Feed”, which isn’t as mnemnonic but sounds cooler.
The fundamental operation of TacFeed is to first select a set of objects, then order those objects for display. The objects are usually comments, but can also be trackback pingss and entries. The ability to order the objects is the real meat of TacFeed. A variety of different properties are available for sorting, the objects can be sorted on an arbitrary set of properties, and the display code can check for differences in properties between adjacent objects to generate headers and footers.
Excited? Well, read on anyway.
Note: This plugin is currently under development and not ready for deployment to weblogs that I don’t administer.
The primary tag for MTTacFeed is the MTTacFeed tag1. This is a container tag that selects, orders, then iterates over the objects. It is vitally important to keep in mind that selecting and ordering two operations are distinct — once an object is selected, it will be iterated over by the container. The selection doesn’t care what order is later put on the objects, and the ordering doesn’t care how the objects were selected.
All other tags for this plugin are used during the iteration, inside the MTTacFeed tag.
The purpose of MTTacFeed is to select feedback objects, comments or trackback pings. The container tag has attributes to control this selection. Related to the feedback objects selected is the set of entries to which those objects are associated. This is termed the entry selection set because we’ll be talking about it quite a bit.
The entry selection set can be implicit, explicit, or both. Feedback objects can be selected based on their own properties (making the entry selection set implicit) or based on properties of the entries (making the entry selection set explicit), or both (making the situation confusing).
After selecting the objects, the objects are ordered. Doing this requires two concepts, metrics and axes. A metric is a way of measuring a property. Ultimately, all ordering in MTTacFeed depends on being able to order the values of a property2 and uses the term “metric” to describe this. A specific instance of using a metric to order the objects is called an axis. The ordering of the objects is done by a set of axes, each of which has an associated metric.
This is analogous to drawing graphs. For example, one might have “number of readers” and “dollars per year” as metrics. One could then use those to create a graph of various weblogs by putting using “number of readers” along one axis and “dollars per year” along another axis. While the metrics are clearly related to the axes, they are not the same thing and it’s important to keep them distinct.
MTTacFeed metrics are always discrete, not continuous. Because of this, it will usually be the case that multiple objects will have the same value for a metric. In that case, MTTacFeed will consider them equivalent for that metric and will put them in an arbitrary (undefined) order along an axis using that metric. Rather than being a problem, MTTacFeed depends on this feature and is designed to take advantage of it.
Axes in MTTacFeed are always nested. There is an outermost axis, inside of which is an inner axis, inside of that a more inner axis, etc. to any desired depth. The outermost axis groups the objects by its metric. Each of those groups is then internally ordered by the next inner axis. This process continues, each grouping being sub-grouped by the next inner axis to the innermost axis. It is this which gives MTTacFeed its power and it wouldn’t work if the outermost axis completely determined the order of the objects.
The last concept needed is that of an edge, which is the change in value of a metric from one object to another. These are the same thing as group boundaries along an axis, but “edge” is shorter to type. MTTacFeed also distinguishes between a trailing edge and a leading edge. The former is change between the current object in the iteration and the previous object, while the latter is a change between the current object and the next object. Note that one object’s leading edge is the next object’s trailing edge. The use of the term “edge” means a change without reference to a particular object. However, in actual use any template code will be processed with regard to a specific object during the iteration, so that in practice the template code must deal with leading and trailing edges.
With the generalities as a background we will consider an example. This is just to illustrate the generalities, which can be difficult for non-math geeks to graph. A more extensive set of examples is provided elsewhere.
Suppose we wanted to display the set of recent comments on a weblog. We don’t want just a flat list3. What we would like is to have a section for each day, then under that a title for each entry that was commented on that day, with the comments grouped under that oldest to newest. In MTTacFeed terms, that would be three axes, using the metrics “day”, “entry ID”, and “comment ID”. MTTacFeed would order by day, putting the comments for each day in an arbitrary order. Each day would then be ordered by the entry, and for each entry by the comment ID. The ability to detect edges lets us put the desired titles in. We can put in a day label for every edge in the “day” axis, and an entry title for each edge in the “entry ID” axis.
The purpose of MTTacFeed is to create this kind of ordering easily so that feeds can be customized for various purposes without having to write Perl code to do it for each feed.
Time isn’t a new concept, but MTTacFeed handles it in a slightly different way.
The most important point is that MTTacFeed has two types of time, “absolute time” and “span time”. Absolute time could also be called “calendar” time. The difference between these two is where the edges are. Absolute time edges are always aligned with the calendar or clock. E.g., the “day” metric from the previous example would have edges at the same points in time as a calendar as an absolute time. Span time, in contrast, has its edges based on the current time, each edge a particular span of time before then without regard to anything else. E.g., “this day” is the same calendar day for absolute time, and within 24 hours of the current time for span time. Both of these are useful and so both are supported.
MTTacFeed accepts time specifications in two formats. The first is the standard Movable Type timestamp, 14 digits of the form YYYYMMDDHHMMSS. Such a specification is always absolute time. The other form, a timespec, is a sequence of digits and letters, the letters selected from this case sensitive list —
| Letter | Time Period |
| s | Second |
| m | Minute |
| h | Hour |
| D | Day |
| W | Week |
| M | Month |
| Y | Year |
The leading digits are treated a number specifying the number of time units indicated by the letter. The digits can have a leading dash to indicate a negative number. For example, “1Y” means “one year”. “1W1D” means “a week and a day”, which is the same as “8D”. 90 minutes can be “1h30m” or “90m” or “2h-30m” or “5400s”. Span time is always specified as a timespec, but a timesec can be used in other situations. Unless otherwise noted, any place a “time” is needed can be specified as either a timestamp or a timespec.
The MTTacFeed tag has the following attributes:
after or before is specified, then objects are discarded from opposite direction. Otherwise, the earlier objectts are discarded. Error: WikiVar “note” not definedinclude_entries attribute and so are not specified here.count is generically useful, particularly to limit the size of the output. offset is useful in conjuction with paging and other techniques that require successive chunks of comments. after and before allow specific time ranges to be selected.
Each axis in the axes attribute is separated by a semi-colon and is of the form
metric [ ( parameter-list ) ] [ = name ]
The option list and name are optional, as indicated by the []s. If there are multiple parameters, they must be separated by commas. Any leading or trailing white space is stripped and then numeric entities are converted to the characters they represent before processing. This can be used to include commas, leading spaces, or quotes in the parameters.
All metrics take an optional parameter of ‘reverse’, which reverses the ordering.
Each axis can be named so that it can be referenced by other MTTacFeed tags. If not specified, the axis is named the same as its metric. Names must be single alphanumeric words, no spaces or punctuation permitted4.
The base_entries and include_entries specifiers require the selection of a set of entries. Both of these tags take (almost) the same set of specifiers, which are very similar to the metric specifiers used for axis definitions. The available specifiers are
After all of the object selection and ordering has been done, the MTTacFeed tag iterates over the objects in order. For each iteration the contents of the container are evaluated and added to the final output.
During an iteration, the container sets up the appropriate MT context for the object. In addition, the associated entry and weblog for the object is placed in the context so that entry and weblog based tags are available in addition to the comment or trackback (as appropriate) tags.
In addition to the top level container class, MTCatFood also provides conditional tags for controlling presentation. These are the MTTacFeedFIfHeader, MTTacFeedIfFooter, and MTTacFeedIfEdge tags.
MTTacFeedIfHeader and MTTacFeedIfFooter are true if a specified axis or any outer one has an edge. MTTacFeedIfHeader checks for trailing edges, i.e. that the current object has a different metric value than the previous object. MTTacFeedIfFooter checks for a leading edge, i.e. that the current object has a different metric value from the next object. The base axis to check is specified by the axis attribute, which can be either the 0-based numeric index of the axis, or the name.
To go back to the previous example, the MTTacFeed container attribute axes would be “span(1D);entry;id”. To put a header for each day, we would use
<MTTacFeedIfHeader axis="span"><h1><MTCommentDate></h1></MTTacFeedIfHeader>because the current object determines the MT context and in this case it is always a comment. The container will also set up the associated entry of the comment in the context, so the entry header can be done using
<MTTacFeedIfHeader axis="entry"><h2><MTEntryTitle></h2></MTTacFeedIfHeader>In this case the cascading edge check insures that a new entry header will be present at the start of each day, even if the associated entry is the same as the previous comment.
The MTTacFeedIfEdge tag is more esoteric and shouldn’t be necessary for most uses. It provides the ability to trigger on any edge boundary on any set of axes. It takes two attributes, header and footer. Each of these is a sequence of axis specifiers (0-based index or name) separated by commas or spaces. The condition is true if any of the specified axes have a trailing or leading edge respectively. Only explicitly names axes are checked, there is no cascading check.
While the set of objects for iteration is by default only comments, it is possible to include trackback pings and entries. To handle these situations, MTTacFeed provides the MTTacFeedIfComment, MTTacFeedIfPing, and MTTacFeedIfEntry tags which are true if the current object is of the appropriate type.
1 The only simple and obvious thing in the entire plugin, so enjoy it while you can.
2 Duh! It’s ordering.
3 Or we wouldn’t be reading this documentation, would we?
4 Really, just how complex do you really need to make the names of the axes?
]]>There are a number of junk spewing scripts out in the Internet Wilds that will pound on the default scripts for comments and trackbacks in Movable Type, regardless of whether the scripts exist or not. Many installations rename these scripts in the hopes of avoiding such junk scripts, but generally to no avail. Whether that succeeds or fails, one is left with an error log full of “404: File not found” errors. This makes it difficult to observe real problems.
Because of this, I decided that I would put in a replacement script that would simply accept the connection and ignore it. Then I realized that if I put a delay in that replacement script, it would slow down the junk scripts. Instead of rapidly passing over targets that are disabled, the junk script would instead spend quite a bit of time waiting uselessly, while imposing very little burden on the weblog host machine. The only way to make progress is to impose burdens on the junkers, reducing the set of them for whom this activity is profitable.
The point being to impose more cost on the junkers than it does on the weblog host. The junkers aren’t magical or invincible, they have their resource limits as well. While the junkers are much bigger than any single weblog, I have no doubt that in aggregate there are far more processing resources belonging to the weblog community than the junker community. Even if it just means that the junkers have to buy bigger hardware, well then they have to spend a lot of money in response to a small effort for each weblogger. That’s still a win.
I implemented this concept and decided that it would be even better if other weblogs did the same thing, to throw ore sand in the gears of the junk machine. You can get the script here or cut and paste the following:
#!/usr/bin/perl -w
use strict;
local $|=1; # Disable buffering
print <<HTML;
Content-Type: text/html
<body>
<div style="font-size:200%;
text-align:center;
background:red;
color:white;
margin-bottom:1ex;
">
Invalid Access
</div>
<p style="border:2px solid red;padding:1ex;">
There is no reference to this script from anywhere else on the Internet.
You can only have accessed this script by guessing its name.
There is no legitimate reason for doing that. Cease your annoying abuse.
</p>
HTML
sleep 30;
print "</body>\n";
You can, of course, customize the message or the style. I strongly recommend against using a style sheet, as the point of this is to use minimal resources on your host. And really, how well designed does the page have to be?
To install
mt-comments.cgi or mt-tb.cgi script was originally).mt.cgi script.mt-comments.cgi or mt-tb.cgi to replace the missing script.Note that this scripts works for either comments or trackbacks, since it doesn’t do anything except print and sleep. Also, only use this if you’ve renamed the original trackback and/or comment script. Do not use this as a direct replacement of either script.
You can see the script in operation here.
While this script should impose very little burden on your webhost, even under rather heavy use, it may not be suitable for installations that run at the limits of their processing power. For those of us in the long tail, however, it should pose no problem. The long tail is the best place for deployment as well.
While I have not observed a burden from this technique, that doesn’t mean it can’t happen. Because of this, I have developed an alternate mechanism that uses PHP instead of Perl so that no external processes are spawned, lowering the burden both computational and in terms of resources (because in many Apache installations, the number of simultaneous external processes is limited). The downside is that this implementation requires the use of ModRewrite and the consequent editing of .htaccess files.
You can download the script here, or cut and paste the text in the box below.
<body>
<div style="font-size:200%;
text-align:center;
background:#822;
color:white;
border:2px solid red;
padding:1ex;
margin-bottom:1ex;
">
Sand Trap
</div>
<p style="border:2px solid red;
padding:1ex;
">
You have been redirected to this script because
you have used an obsolete resource to which
no references exist on this website. This makes
you presumably a junker, and therefore your
session has been bogged down with this webpage.
</p>
<?php
ob_flush();
flush();
sleep(30);
?>
<p style="text-align:center;
border:2px solid red;
padding:1ex;
margin-top:1ex;
">
If you are going to abuse me, I will abuse you right back.
</p>
</body>
Put this script somewhere where the weblog can access it without a redirection1, name it sand-trap.php, and set the permissions to 755. Then edit the .htaccess file to do the rewrite.
For this example, it is presumed that
sand-trap.php is installed in the root directory of the weblog domain. E.g., for this weblog it is installed at http://blog.thought-mesh.net/sand-trap.php (try it if you’d like)..htaccess file is in the Movable Type install directory.RewriteEngine On RewriteRule ^mt-comments.cgi /sand-trap.php [last] RewriteRule ^mt-tb.cgi /sand-trap.php [last]
You can also install the .htaccess in the root directory of the domain, which is what is done on this weblog2.
RewriteEngine On RewriteRule ^cgi-bin/mt/mt-comments.cgi /sand-trap.php [last] RewriteRule ^cgi-bin/mt/mt-tb.cgi /sand-trap.php [last]
You would, of course, need to change cgi-bin/mt to the local path to your Movable Type install directory.
Note: This will render any scripts with those paths inaccessible, so don’t do this if you haven’t renamed those scripts. Alternatively, you could leave this in to turn comments / trackbacks on and off by putting a leading ‘#’ on the appropriate lines to change them to comments (or not).
As a side benefit of this mechanism, if you use the MT 3.2 Patch: Trackback By Name modification, you can use ModRewrite to drop junkers still using the now invalid numeric form in to the sand trap as well. This is what you would use in a .htaccess file in the MT install directory, presuming that sand-trap.php was in the domain root directory.
RewriteRule ^mt-tb.cgi/[0-9]+ /sand-trap.php [last]
1 I.e., accessible from the same webserver. This is important because if a redirection happens, the junker will drop the connection and the goal is to keep him on the line as long as possible.
2 Because I moved from cgi-bin/mt to scgi-bin in the past, but the junkers keep hitting the scripts in the no longer extant cgi-bin/mt directory. Because that directory doesn’t exist, I can’t put the .htaccess there. Instead, I put it in the root directory to handle both the old and current directories.
The trackback API for Movable Type 3.2 uses the internal numeric ID of the trackback object as the key. This has two problems:
This was unavoidable in previous versions of Movable Type, but with the release of 3.2 and its use of globally unique “basenames” for entries, we can do better.
This modification changes the trackback API to use identifying strings instead of numerics as the trackback key. The trackback object identifiers become completely internal (as was done for entry identifiers in 3.2). This overcomes both of the issues listed above.
This project is currently in beta. It has been deployed only several production weblogs, including this one. You can test it out by doing a trackback to this entry using the URL in the “Trackback URL” link below, or using the URL for this entry with “/ping” appended. Please put text that indicates a test if you do test it, so I can clean those out.
NB: This modification explicitly forbids the use of numeric trackback ids. If installed and followed with a complete rebuild, this should not affect legitimate weblogs as the trackback URLs are pulled from your webpages, which will have the new, correct trackback URLs in it.
Two files in the base distribution must be modified. You can pick up the modified versions of the files here or, if you’re paranoid like me, you can do the modifications yourself. Once the files have been modified, you will need to a full rebuild to update all of the trackback URLs. At that point the modified trackback API should be fully operational.
The lib/MT/App/Trackback.pm file must be modified. Note that there are two files named Trackback.pm in the distribution, be sure to edit the correct one.
Around line 97, there is a subroutine _get_params. Remove this subroutine and replace it with the following subroutine:
sub _get_tb {
my $app = shift;
my ($tb, $pass); # Trackback object and password to return
my ($key, $name); # local vars for internal computations
if (my $pi = $app->path_info) {
$pi =~ s!^/!!; # drop leading slash
($key, $name, $pass) = split /\//, $pi;
if ($key =~ m/\d+/) {
$app->error($app->translate(
'Numeric trackback IDs are no longer accepted'));
} elsif (lc($key) eq 'entry') {
require MT::Entry;
$name =~ s/\..*$//; # strip any extension
if (my $entry = MT::Entry->load({ basename => $name})) {
$tb = MT::Trackback->load({ entry_id => $entry->id});
$app->error($app->translate(
'No trackbacks for entry with basename [_1]', $name))
if not $tb;
} else {
$app->error($app->translate('No entry with basename [_1]', $name));
}
} elsif ($key =~ m/^cat/i) {
require MT::Category;
if (my $cat = MT::Category->load({ label => $name })) {
$tb = MT::Trackback->load({ category_id => $cat->id });
$app->error($app->translate(
'No trackbacks for category with label [_1]', $name))
if not $tb;
} else {
$app->error($app->translate(
'No category with label [_1]', $name));
}
} else {
$app->error($app->translate(
'Invalid trackback target key [_1]', $key));
}
} else {
$app->error($app->translate(
'Track request URL incorrectly formatted.
The trackback target path information was missing'));
}
($tb, $pass);
}
Around line 150, in subroutine ping, change
my($tb_id, $pass) = $app->_get_params;
return $app->_response(Error =>
$app->translate("Need a TrackBack ID (tb_id)."))
unless $tb_id;
require MT::Trackback;
my $tb = MT::Trackback->load($tb_id)
or return $app->_response(Error =>
$app->translate("Invalid TrackBack ID '[_1]'", $tb_id));
to
my($tb, $pass) = $app->_get_tb;
return $app->_response(Error => $app->errstr) unless $tb;
Around line 185, change
no_utf8($tb_id, $title, $excerpt, $url, $blog_name);
to
no_utf8($title, $excerpt, $url, $blog_name);
Around line 213, change
$ping->tb_id($tb_id);
to
$ping->tb_id($tb->id);
In subroutine rss, around line 369, change
my($tb_id, $pass) = $app->_get_params;
my $tb = MT::Trackback->load($tb_id)
or return $app->_response(Error =>
$app->translate("Invalid TrackBack ID '[_1]'", $tb_id));
to
my ($tb, $pass) = $app->_get_tb;
return $app->_response(Error => $app->errstr) unless $tb;
The file lib/MT/Template/ContextHandlers.pm should be modified. This is not strictly required, but if this is not done then you will have to construct all trackback related data by hand in the templates rather than using the standard tags.
In subroutine _hdlr_entry_id, around line 1125, change
$path . $cfg->TrackbackScript . '/' . $tb->id;
to
$path . $cfg->TrackbackScript . '/entry/' . $e->basename;
In subroutine _hdlr_entry_tb_data, around line 1138, change
$path .= $cfg->TrackbackScript . '/' . $tb->id;
to
$path .= $cfg->TrackbackScript . '/entry/' . $e->basename;
In subroutine _hdlr_category_tb_link, around line 2639, change
$path . $cfg->TrackbackScript . '/' . $tb->id;
to
$path . $cfg->TrackbackScript . '/cat/' . $cat->label;
There are several things to keep in mind once this modification is installed.
One of the drivers for this modification was a request for “friendlier” trackback URLs. In particular, the desire was to be able to have other weblogs link via trackback to a post by using the URL of the post with “/ping” appended as the trackback URL. This requires
.htaccess files to enable mod_rewriteAlso note that this works only for individual archives.
To set it up, in the top level directory for the individual archives, place text like the following in a .htaccess file:
RewriteEngine On # Support trackback pings by appending "/ping" to an individual archive URL. RewriteRule /([^/]+)/ping$ /cgi-bin/mt/mt-tb.cgi/entry/$1
You need to make sure that the path “/cgi-bin/mt/mt-tb.cgi/” is correct for your installation. This is easy to find, simply look at your current trackback URL.
In theory, this should be easily extensible to supporting category trackback pings, although I never use categories so I have not experimented on it directly yet. Note that the URL must be of the form “…/cat/…” instead of “…/entry/…” for category trackbacks.
NB: The name logic for trackbacks automatically strips extensions, so that you can use both “my_cool_post” and “my_cool_post.html” as the name for the trackback URL. This was done to support this technique.
One effect of this modification is to make the trackback URLs noticeably longer. This can cause problems with formatting, particularly of popups. What I have done is change explicit display of the trackback URLs to a link with the link text “Trackback URL”. The reader can then either right-click and use the “copy this link” option (available in FireFox, IE and Opera) or use the “friendlier” trackback URLs.
This project originally inspired by a request from Sherwin Techico on the ProNet mailing list
]]>The new plugin configuration settings support in MT 3.2 takes some getting used to but it is well worth the effort. One of the issues, however, is that for many plugins that have per weblog configuration data, it would be handy to use the system level settings as another level of defaults so that any weblog that wasn’t explicitly configured would use the system settings instead of the hardwired defaults. This turns out to be achievable with a reasonable amount of effort.
There are two places which have to be dealt with to achieve the desired effect:
This description presumes that you have created your plugin as a subclass of MT::Plugin as is recommended. The implementation consists of adding two methods to your plugin class and then using those methods elsewhere in the plugin.
The MT 3.2 distribution has no mechanism for detecting whether a weblog has a specific configuraiton. This can be remedied by putting a subroutine to do that in to your plugin class.
# Return the config object for the scope if it exists, undef otherwise.
sub test_config_obj {
my $plugin = shift;
my ($scope_id) = @_;
my $key;
my $scope = $scope_id;
if ($scope && $scope ne 'system') {
$scope =~ s/:.*//; # strip off id, leave identifier
$key = 'configuration:'.$scope_id;
} else {
$scope_id = 'system';
$scope = 'system';
$key = 'configuration';
}
# if it's already in the cache, return it.
return $plugin->{__config_obj}{$scope_id}
if $plugin->{__config_obj}{$scope_id};
# otherwise try to load it.
require MT::PluginData;
my $pdata_obj = MT::PluginData->load({plugin => $plugin->name(),
key => $key});
# if we succeed in loading, cache it
$plugin->{__config_obj}{$scope_id} = $pdata_obj if ($pdata_obj);
return $pdata_obj;
}
This is a modified clone of the get_config_obj subroutine. If the configuration is found, it is cached to make subsequent calls to retrieve it fast. Therefore it’s not a Bad Idea to call the test method and then the get method.
Once this is present, then defaulting to system settings for non-configured weblogs is easy, presuming that $plugin is set to your plugin object.
if ($plugin->test_config_obj($scope)) {
$settings = $plugin->get_config_hash($scope);
} else {
$settings = $plugin->get_config_hash('system');
}
After this, $settings is set to the weblogs specific settings, if present, otherwise the system settings or, if those are missing, the hardwired defaults.
My personal preference is to use an “operation” class for my plugin logic that is instantiated when the plugin has to do its work. That class loads up the settings using this logic during construction (in the new subroutine) and caches them for use everywhere else.
If a user goes to configure the plugin for a specific weblog and there is no configuration data for that weblog, the defaults loaded in to the configuration interface should be the system defaults because
We can do this by overriding the default logic in the base class for our plugin class with this subroutine:
sub apply_default_settings {
my ($self, $data, $scope_id) = @_;
# If the defaults are being applied to a weblog, then copy down
# from the system settings to supply the default values.
if ($scope_id =~ m/:/) {
my $system_data = $self->get_config_hash('system');
foreach (keys %$system_data) {
$data->{$_} = $system_data->{$_}
if not exists $data->{$_} or not defined $data->{$_};
}
}
return $self->SUPER::apply_default_settings($data, $scope_id);
}
Some Movable Type plugins require database tables to store their information because it is too large for the simple plugin settings data. It has always been a problem to create these tables automatically, but with MT 3.2 this is now possible.
This implementation description presumes that the plugin and the plugin data class are correctly registered in accord with Movable Type 3.2 requirements. All of that is covered elsewhere (like here), although I learned primarily by reading the code and its internal documentation, and looking at other working plugins. The write up on the Movable Type website isn’t worth reading (incomplete and obsolete) so I recommend against looking there.
When using the install_properties mechanism to define the data elements of a plugin, use ‘column_defs’ instead of ‘columns’. This is a hash, not an array, which maps column names to column descriptors. These descriptors are the standard SQL description of a column. Some standard types to use are
id’ — ‘integer not null auto_increment’integer not null’string(255)’. This one I am not so clear on, whether the number matters for performance or, if it does, what the optimal value is. It will be transformed in to a variable sized string, so it doesn’t matter in terms of functionality.This is the code used in my Webiki plugin. It is in the configuration template generation logic. The Webiki plugin defaults to not transforming the text and the user must therefore visit the configuration page before it works. I am not sure how expensive the table existence checks are, so I wanted to not have them done every single time the plugin was loaded.
my $db = MT::Object->driver();
if (not $db->table_exists('Transfinitum::Webiki::Word')) {
my $error = 'Database handle from driver not valid';
my $statement;
my $dbh = $db->{dbh};
if ($dbh) {
$error = '';
for ( $db->fix_class('Transfinitum::Webiki::Word') ) {
$statement = $_; # cache for later use in error message
if (not $dbh->do($statement)) {
$error = $dbh->errstr;
last;
}
}
}
if ($error) {
MT->instance->log(
MT->translate(
'Failed to create database tables for Webiki plugin - [_1]'
, $error
));
$tmpl .= <<INIT;
<p style="color:red;">Failed to create database tables for Webiki plugin.
<br />Statement: ‘$statement’
<br />Error: $error.</p>
INIT
} else {
$tmpl .= '<p>Created database tables for Webiki plugin.</p>';
}
}
$tmpl;
The first two lines check for the existence of the tables for the ‘Transfinitum::Webiki::Word’ object, which is the type of object stored in the database table. If not, then we create them. The fix_class method does not actually fix the class, but instead returns the appropriate database statements to do so. This method is generally used in the upgrade process, but if the table doesn’t exist (as we’ve determined) then it emits only the table creation statements.
After that, we execute the statements one by one, checking for errors. If errors are encountered, we log that and attach it to the settings display. If the tables are created successfully, we make a note of that as well.
You can see this code used in a working plugin by looking at the source for Webiki. Working code is always a good companion to documentation.
]]>First, execute the following on the command line:
perl -e "print crypt('password', 'ac');"
Substitute the password you want for the string ‘password’ in the above command. The ‘ac’ can be any two characters, it doesn’t matter, but they must be present (that’s the “salt” for you UNIX™ geeks). This will print a set of apparently random characters. Take those characters and put them in to the “author_password” column of the corresponding row of the “mt_author” table in the Movable Type database. Do not use any DB encryption function — Movable Type does that itself and uses the DB column as a simple text field.
]]>This article describes my anti-junk defense grid for Movable Type. It is a layered defense, different aspects working together to reduce the burden of maintaining successful defenses, without overly restricting users of the weblog1.
I use a combination of technologies as a defense in depth, so that even if there is penetration, it is rarely much effort to clean up.
SpamLookup is a junk filtering plugin that is installed in Movable Type by default, starting with version 3.2. This is a very useful plugin and I use it extensively. I primarily make use of the word filter to scan for indicators of junk posters and ban specific domains. While SpamLookup doesn’t have any bulk delete functionality, MT 3.2 itself allows one to search comments for specific strings, which is enough to make bulk clean up tolerable. With my defense grid in place, however, I haven’t had to do that for quite a while.
While the distributed SpamLookup is useful, there were many things that I observed that I wanted to check for that were not possible. Initially I wrote my own filter to do these checks but later I created my own SpamLookup Extension to be able to apply filters to specific fields in the entries. This permits much broader filters and more complex patterns. For instance, one can simpy forbid the character sequence “poker” or “sex” in a home page URL or commentor name without affecting normal use of the word in the actual comments. Or, in terms of patterns, one can forbid commentor names that are longer than some specific number of characters.
This layer provides an excellent first defense that gets at least 90% of the incoming junk. Here is my base set of filters. It has a lot of examples of how to take advantage of the field capability. I do tend to tweak it a bit, but it’s got most categories that are useful so it’s mostly a matter of cloning an existing filter and using a new word.
Simple Junk Filters is a small filter framework that lets me create PERL based filters and easily set them up to run and be tunable via the plugin configuration screens. This used to do much more, but now that I have extended SpamLookup it is down to two tests, but both of these catch quite a bit of junk. Also, should I find some other property of junk I need code to check for, I can put it in this plugin very rapidly with full configuration.
AutoBan is an IP banning plugin that helps
AutoBan keeps a ‘.htaccess’ file updated to ban the IP addresses of junk objects. As new comments or trackbacks are junked, the IP addresses are automatically banned if there too many junk objects from that IP address. IP addresses are unbanned when the junk entries are deleted (directly or via automatic cleanup) or the junk object is marked as not junk. The key rationale is that the cost of starting up the Movable Type application is large, so any filtering that can be done to prevent that should reduce the load on the server. See the page for MTAutoBan for a more detailed discussion of the performance issue.
While this doesn’t help as much as I hoped, it still seems to keep flooding under control. It also helps protect multiple weblogs in a single install because banned addresses are banned for all the weblogs. This weblog gets very little junk because the junkers hit Thought Mesh first and are banned before they can hit this weblog.
I use MT 3.2 Patch: Trackback By Name to stop junkers who guess at trackback ping URLs, along with ModRewrite to redirect numeric ID based trackbacks to a sand trap. This definitely seems to have slowed down the trackback junk.
I have removed pop up windows for trackbacks and comments and used ModRewrite to send any requests for those popups to the sand trap. That presumably should help reduce the server load both by slowing up the junkers and by using many fewer webhost resources (as I use the PHP variant, there is no CGI overhead).
The ModRewrite logic used is
RewriteCond %{QUERY_STRING} __mode=view
RewriteRule mt-tb[.]cgi /sand-trap.php [last]
RewriteCond %{QUERY_STRING} __mode=view
RewriteRule mt-comments[.]cgi /sand-trap.php [last]
1 For instance, some weblogs forbid any URL in a trackback excerpt, which is very burdensome because one normally puts the link to the target post early, which puts it in the excerpt. I’ve just stopped linking to such weblogs. Also, I hate captchas — I don’t comment on websites with those, either.
]]>This is a collection of various junk filters I use which are not implementable in other junk filter plugins. Many of the original set have been removed because they can be done with the SpamLookup Extension.
Each filter can be tuned to have a distinct weight via the top level plugin settings page. Setting a weight to zero disables the filter.
This plugin also provides a nice platform for adding other simple filter checks.
Nothing to do, it’s an install and forget filter. If you don’t like a filter, configure the weight of that filter to be zero. Note that the plugin returns a single junk filter score, not one per filter, that is the sum of the scores of the filters that matched.
To add your own filters, you can add a new subroutine to the plugin. It takes two arguments
MT::Comment or a MT::TBPing.The subroutine should return a true value if it matched on the object, false otherwise. The filter weight is controlled via the configuration, not the code.
After writing the subroutine for the filter, add a description of the filter to the plugin construction. That’s it, the filter will now run with a configurable weight.
]]>spamlookup.pm file from the distribution and replace the file in the plugins/spamlookup/lib directory.
SpamLookup Extension is now available for
The modification provides the ability to apply word filters to specific fields in the comments and trackbacks, rather than the conglomeration of all fields. There are a number of specialized checks that I have found useful, most of which I had previously put in to a custom spam filter.
The new syntax for filter lines is
word ( fields ) weight
where
A word can be either a space delimited literal word or a ‘/’ delimited regular expression. In the latter case, the characters ‘-ismx’ are permitted to directly following the trailing ‘/’. If present, these are passed to the PERL regular expression engine to control the interpretation of the regular expression.
The valid field keywords are
| FIELD | MEANING | DISPLAY |
| name | Name for a comment author | Commentor |
| Email address for a comment author | ||
| home | Homepage URL for a comment author | URL |
| content | Text content of a comment | (text box) |
| blog | Weblog name for trackback source | Source Site |
| title | Title for the source post of the trackback | Source Title |
| source | Source URL for a trackback | URL |
| excerpt | Trackback excerpt | (text box) |
| url | Equivalent to home or source | |
| text | Equivalent to content or excerpt | |
| all | All fields together, separated by newlines | |
If no fields are specified, “all” is used, thereby preserving (almost) the orginal behavior and syntax. The url and text fields are provided to make scanning equivalent fields for comments and trackbacks easy. If multiple fields are specified, they are all scanned in order. A match on any field counts as a match.
Most of these are from my customized spam filter, which can now be simplified. All of them are things I have seen in comment and trackback spam.
Note that some of these are simply not possible in the original release (particularly the empty field checks). Others are possible but too broad to be practicle (such as checking for archive like links as a home page, or double dashes).
One feature that has come in handy is the ability to search for phrases at the beginning of a comment, which detects spammers with much less impact on legitimate commentors. For instance, one spammer starts his comments with ‘Hello, Admin!’. This can be detected with
/^Hello, Admin!/ (text)
The ‘^’ means “match only at the start” when inside a regular expression (denoted by the ‘/’ characters). The other handy character is ‘$’, which means “match only at the end”. Together with ‘^’ this means you can match on phrases that are the entire comment, not just part of it. E.g., if a spammer just puts the word ‘Hi.’ in his comments, you can catch that with
/^Hi\.$/ (text)
Note that we have to put a backslash in front of the ‘.’ because otherwise that means “match any single character”. With this, some one who writes ‘Hi.’ at the start won’t be matched, if he writes any additional text.
One common request is to ban a specific email address. This is now trivial. To ban the email address “neo@hotmail.com” you can do
neo@hotmail.com (email)
If you want to detect the word “poker” in email address, commentor name, or home page URL, you can do
poker (email url name)
and your commentors can still use the word in the text without impediment.
The weight of a filter can be negative, which causes it to be a white listing. If I wanted to give myself a bypass, I could use the rule
Annoying Old Guy (name) -10
which would subtract 10 from the junk score of all of my comments so that my comment would pass even if it hit several filters. This could easily be used to give bypasses to other commentors by name, email, or home page URL. One could even use this to create a magic bypass word, say ‘ciscomyyahoo’. Put in the rule
ciscomyyahoo (content) -10
and then when you want a bypass, put the magic word in an HTML comment, e.g. <!–– ciscomyyahoo ––> in your comment and you’re through the filters yet other people don’t see the magic word.
My current working set of filters can be found here, which has numerous other examples.
There a few minor functional differences.
The original distribution of SpamLookup had bugs in the handling of decoded1 text where the decoded version of the text would not be scanned if the raw version did not have any hits by filters for junk filters. In the case of moderation filters, the decoded text would always be scanned, regardless of hits in the raw text (making the raw text scan pointless).
The new version now applies filters per field first to the raw text for the field, and then, if the raw text did not have a match, the decoded version (if different) is scanned. A match in either case counts as a match for the filter.
The processing of standard words (not regular expressions) is improved. Previously, words that started with non-word boundary characters would never match (because expressions like ‘\b<’ never match). These cases are now handled correctly.
The base implementation has a problem where backreferences do not work correctly because the regular expression is compiled before the outermost parentheses are added leading to various problems. This does not occur in this version and the workaround suggested won’t break. The only thing to keep in mind is that all backreferences need to be incremented by one before being used.
The original release, when combinging the fields in to the combined text, would prefix each field with the string “field:” where field was one of ‘name’, ‘email’, ‘url’, ‘text’ for comments and one of ‘blog’, ‘title’, ‘url’, ‘text’ for trackbacks. Presumably this was done to provide a semblance of the functionality of my modification (at least, one could check if a specific field began with a specific filter word) but as there are no comments in the code there and no documentation, this is only speculation. In any case, I could see no use for it at all in this modification so it was removed.
If a match occurs for a specific field other than ‘all’, the name of the field is added to the pattern in the log message on the comment / trackback.
For each word filter match, the specific score for that match is logged.
The patterns and matched text are HTML encoded before being placed in to the log so that pattern or match text that contains HTML code does not disturb the log display. In addition, literal question marks ‘?’ are transformed in to entities because they mess up the log display (although I have not had the time to track down why that is).
The MT 3.34 replacement lib is available here. This is currently in use on multiple live weblogs.
The new version has a bit more tuning, although it’s unlikely to be noticeable in the real world. I have added more comments in the code for the curious and tweaked the log messages to be a bit clearer.
The only known potential issue is with Japanese and word boundaries. As best as I understood the code, the special checks for that should still work correctly. The original checks were removed, as they should be handled correctly by my bug fix for broken word boundaries in the original version.
1 “Decoded” means entities decoded to their textual equivalents.
]]>MTAutoBan is a plugin for Movable Type. It maintains an Apache webserver configuration file (also known as a “.htaccess” file) that bans IP addresses in the Apache webserver. The set of banned addresses is generated from the junk objects stored in the Movable Type database. Whenever the set of junked objects changes, the Apache configuration file is updated.
The goal of this plugin is to slow down the flood of junk objects by banning the IP source addresses that generate them. This makes it easier to check the junk objects for bad filtering and makes denial of service effects from excessive amount of junk much less likely. By doing the banning at the Apache webserver level instead of in Movable Type itself, the runtime cost of the banning is minimized. With a good set of filters, even large1 groups of systems are rapidly banned with little effect on the weblog.
As a result of further experience, I added the ability to redirect requests instead of simply banning them, because it seems that many junkers notice 403 error eventually and rotate attacks over to new machines. Redirection is intended to thwart this.
Because of the large numbers of compromised computers used to generate junk, the maintenance cost of banning the associated IP addresses must be near zero. This plugin achieves that goal. No maintenance is required once installed, and the defaults are good enough that initial configuration is not even necessary.
To make the banning as automatic as possible, the configuration file is updated whenever
Current Version: 1.2.3
Beta Version for MT 4.0 Compatibility: 1.2.4
MTAutoBan requires
All other Perl modules required by MTAutoBan are also required by Movable Type.
AutoBan under the plugins directory in your MT installation directory.AutoBan directory.Note: If you installed a version prior to 1.1.0, you should remove the no longer in use file
extlib/Transfinitum/Apache/IPAccess.pm
MTAutoBan is designed to be a “zero configuration” plugin — unless you like to fiddle with things, you should have no need of configuring MTAutoBan. If you do read through this section and there are settings that you don’t understand, simply ignore them and leave them unchanged. These settings are for control-freaks like me who have psychological problems that do not permit them to tolerate anything they do not have absolute control over. Normal, well-adjusted people can get on with their lives instead.
To configure MTAutoBan, go to the global plugins configuration page. This can be reached from the “Plugins” link on the MT main page in the “System Shortcuts” area. MTAutoBan should be listed as one of the plugins available. The plugin has several configuration options.
ErrorDocument directive in its section of the access file to override the page that would normally be used.mod_rewrite to redirect requests instead of denying them. This option has unknown performance implications and so should be used with caution (see here).In addition to these configuration options, there is also a check box labeled “Force access file update”. If checked, when the configuration is saved the access file is updated.
MTAutoBan has MT tags to display information about its operations.
| MTAutoBanBannedCount | The number of banned IP addresses. |
| MTAutoBanUniqueCount | The number of unique addresses in the junk objects. |
| MTAutoBanObjectCount | The number of junk objects checked. |
| MTAutoBanThreshold | The number of junk objects needed to ban an address. |
| MTAutoBanLastUpdated | The time and date of the last access file update. This takes a “format” attribute to format the time. It behaves identically to the “format” attribute for standard MT time / date tags. |
The overall performance characteristics of this plugin are unknown due to lack of an installed base. It has been running on all of my MT based weblogs for a couple of years without any apparent negative performance impact, but that is not conclusive.
The theory is that while updating the access file is expensive, it is significantly less expensive than loading up the MT application itself, which is done even when junk is caught by the filters. My experience has been that while there are a number of single hit junkers, there are many who flood a single weblog with a large number of requests in a short time period. It is those that MTAutoBan is designed to frustrate.
MTAutoBan does file locking on the access file and if it fails to get the lock, it cancels its access file update on the presumption that another instance of itself is already in the middle of an update. Because all addresses are updated every time2, if an address is not added for this reason it will be on the next access file update so at most there is one more junk object than optimal. In exchange, the total server load per weblog is limited to a single update at any moment in time.
Support for mod_rewrite adds another level of complexity to performance issues. Because MTAutoBan is targeted at access files, it cannot use the RewriteMap directive, which is only available to the main Apache configuration file. Therefore, it uses stacked RewriteCond directives followed by a RewriteRule that rewrites all URLs to the redirection target. I have very little data on the performance impact of processing 100 - 200 RewriteCond directives each with 50 alternate clauses in their regular expression is. It’s a lot of data, but the regular expresions are all literals.
In practice, I used it briefly with ~7,000 addresses without an obvious performance impact, which is rather weak evidence. This weblog has ~5,000 addresses banned with mod_write redirection (you can see the exactly number on the upper right of this page). If there is an impact, it should show up while using the Movable Type interface. If it has, I have not noticed. It may be, however, that I happen to use or run on a lightly loaded webserver. I recomend caution when using this feature.
MTAutoBan has its own section of the .htaccess file and preserves content outside of its area when updating the file. This is done so that other, non MTAutoBan directives can be kept in the file. The most common expected use of this feature is white listing, i.e. allowing specific hosts / IP addresses access regardless of what AutoBan does. For example, if your ISP supplied IP addresses was 192.168.56.56, you might want to white list it to decrease the risk of losing access. To do that, you would put the following in the .htaccess file.
order deny,allow allow from 192.168.56.56
This instructs the Apache webserver to favor allow from over deny from and then to allow the IP address 192.168.56.56, achieving the desired effect. The same technique can be used to permit specific proxy addresses or domains (see here for additional information). This content will be preserved by MTAutoBan.
Versions prior to 1.0.3 had a bug where multiple instances of could interfere and scrozzle the .htaccess file. The symptoms are that any access to MT scripts causes a 500 (internal server) error. If this occurs, simply delete the .htaccess file via FTP or your webhost’s standard file management then install a version 1.0.3 or later.
.htaccess file would cause a spurious warning..htaccess file could get scrozzled under high loads.MT::PluginData library requirement for the template tags.1 As of this writing, the largest observed attack was roughly 1800 distinct source addresses. These were all detected and banned with no noticeable effect on the weblog. Note that this is for posting attacks only — reading attacks are not protected against.
2 You might think that it would be more efficient to do incremental updating, but it’s not. And since it’s not, it is much more robust to do everything every time.
]]>XMLRPCServer.pm file from Movable Type. It is (almost) completely backwards compatible with the original version, but provides three sets of extensions.
To install this, replace the existing file in lib/MT with the modified version. Be sure to have a backup copy of the original somewhere, although you can recover if necessary by downloading the original Movable Type distribution and copying the original file from there.
publishPost will now set the post state to “PUBLISH” if it is not already. This resolves an issue I have with w.bloggar leaving new posts in “DRAFT” state. In my view, if the client calls this method to publish a post, the post should end up published, i.e. publically visible.editPost and newPost will now accept the trackback URLs to pick as a space separated string, in addition to an array of strings. This fixes an issue with w.bloggar.editPost supports modifying the author of a post. It still requires that the specified author be associated with the weblog for the post.If the name and password are specified as empty strings then the call still succeeds but only published posts are returned. Draft posts are ignored.
]]>