We have a pattern abuser showing up on English Wikipedia, creating
page after page full of 1-pixel versions of random images from
throughout the site. This appears to be a slow ramp-up to a larger
denial of service attack on the image servers for en.wp.
The pattern is easy to spot, once they do it, but "easy" in this case
is normal reaction time of admins / alert users, most of whom haven't
seen the pattern up close to know what's going on.
Is there anything that can or should be done ahead of time, at the
site operations level or developer level, to try and keep the presumed
end-case massive DOS attack on the systems from succeeding?
They're telegraphing their actions out pretty obviously, practicing
for what I strongly suspect is coming. But I don't know that we can,
with in-wiki tools, find them / block them out effectively enough...
--
-george william herbert
george.herbert(a)gmail.com
I did some refactoring yesterday on the title prefix search suggestion
backend, and added case-insensitive support as an extension.
The prefix search suggestions are currently used in a couple of
less-visible places: the OpenSearch API interface, and the (disabled)
AJAX search option.
The OpenSearch API can be used by various third-party tools, including
the search bar in Firefox -- in fact Wikipedia will be included by
default as a search engine option in Firefox 3.0.
I'm also now using it to power the Wikipedia search backend for Apple's
Dictionary application in Mac OS X 10.5.
We currently have the built-in AJAX search disabled on Wikimedia sites
in part because the UI is a bit unusual, but it'd be great to have more
nicely integrated as a drop-down into various places where you might be
inputting page titles.
The new default backend code is in the PrefixIndex class, which is now
shared between the OpenSearch and AJAX search front-ends. This, like the
previous code, is case-sensitive, using the existing title indexes. I've
also got them now both handling the Special: namespace (which only AJAX
search did previously) and returning results from the start of a
namespace once you've typed as far as "User:" or "Image:" etc.
More excitingly, it's now easy to swap out this backend with an
extension by handling the PrefixSearchBackend hook.
I've made an implementation of this in the TitleKey extension, which
maintains a table with a case-folded index to allow case-insensitive
lookups. This lets you type in for instance "mother ther" and get
results for "Mother Theresa".
In the future we'll probably want to power this backend at Wikimedia
sites from the Lucene search server, which I believe is getting prefix
support re-added in enhanced form.
We might also consider merging the case-insensitive key field directly
into the page table, but the separate table was quicker to deploy, and
will be easier to scrap if/when we change it. :)
-- brion vibber (brion @ wikimedia.org)
On Jan 31, 2008 11:46 AM, <siebrand(a)svn.wikimedia.org> wrote:
> * add OBSOLETE for GiveRollback, Makebot, Makesysop, and Oversight
I might be wrong, but it seems to me that Oversight does a lot more
than provide an interface for adding a new group. It adds the
functionality -- the hiderevision right doesn't exist in core. In
fact, Oversight doesn't provide an interface for adding the right at
all, and is completely unaffected by the Userrights improvements,
isn't it? Oversight was always added by stewards using
Special:Userrights.
In findColonNoLinks replace:
if( $pos === false) {
with
if( $pos === false || $pos == strlen($str)-1) {
Rationale: currently this input renders without a colon:
;Example:
:Blah blah
I don't know if there is a reported bug for this, but the behaviour
has bitten me once or twice, and I don't think there's anything useful
in treating a trailing colon as the start of a (non-existent)
definition.
Steve
PS It may be preferable to implement this by searching the left($str,
strlen($str)-1) or something, but I leave that to people who actually
know PHP :)