This patch limits users who are not in the known-good users
list ('autopatrol') to creating 5 pages per day.
The vast majority of our spam comes from the creation of new
pages. This patch will limit the usefulness of each spammer
account, by limiting the number of pages each can create.
By setting the number at 5 initially, it is not expected to
have an impact on legitimate new users playing with the wiki
for the first time. Neither will it have an impact for many spam
accounts, but at least it provides and upper limit for cleanup.
Relevant references:
* Rate limts https://www.mediawiki.org/wiki/Manual:$wgRateLimits
* User rights https://www.mediawiki.org/wiki/Manual:User_rights
Change-Id: Iabe785fedb121a32d8adac5a490d9b5b9f40219f
Since https://review.openstack.org/#/c/368114/
introduced the 'autopatrol' group, a team has been proactively
verifying and adding known-good users to the group as edits are
made.
The group currently contains almost 300 members, and most non-spam
edits made on the wiki today are made by users with membership of
this group.
To date, group membership allowed bypassing the CAPTCHA for edits.
This patch proposes 3 additional, low impact, changes to further
help with our ongoing spam problem.
1) Restrict File Uploads to members of the autopatrol group
Non-Spam file uploads on the OpenStack wiki are relatively rare,
particularly for new users, and anyone who has uploaded a file in the
past is already covered by the autopatrol group.
Restricting this ability to verified users would completely remove
a major spam avenue from the current attack.
2) Restrict Page Moves to members of the autopatrol group
Page moves tend to only be conducted by very experienced users of
the OpenStack wiki, who have all been around a long time and are
members of the autopatrol group. They are also very rare outside of
spam situations.
In spam situations, page moves make clean-up doubly difficult and
allow spammers to work around new page creation restrictions.
Restricting this ability assists somewhat with the spam attack
3) Restrict Write API access to members of the autopatrol group
Author is unaware of anyone in the OpenStack community using the
MediaWiki write API, however the fact that it is open for all users
seems to make it a very tempting attack avenue for spammers.
Change-Id: I8a59e2a0d0fcddc0f2774a8a704c1ac57003d6a8
Add a grant for all clients to read files from the images directory.
Without this, all requests for images are denied.
Change-Id: I50817ce3170453b6522e01ad3e1a3d503f59f9fb
If disallow_robots is enabled, make sure we not only install and
alias the robots.txt file but also grant permission to read it and
omit it from our general article URL rewrites.
Change-Id: I9532dd8fd18010aaad388e8fdcbc3051fc653234
autopatrol users have been human-verified to be legit.
Therefore, they don't need to go through the pain of CAPTCHA
This patch adds the necessary permissions.
Change-Id: I501eae00f471ee13525073d39c8e51a7ccb67fdc
Add a disallow_robots parameter which can be used to disallow
indexing of all site content by robots. This is particularly useful
for test deployments where you don't want extra (often stale) copies
of your content to show up in search engines.
Change-Id: Ic62a72555315bd344db338809920a3605f17c8c6
Since $type and $source are both class parameters, we can't
interpolate $type in the default definition for $source. Instead
redefine $source inside the resource if it's unchanged from the
resource default.
Also make the contents of /src/mediawiki/w require the vcsrepo
resource for it. Early creation of the directory causes vcsrepo to
fail to clone into it.
Change-Id: I9b447173d4966f03a195825047cf25afc1a4afd6
To make this module more downstream-friendly, abstract out any
references to OpenStack and turn them into classvars.
Change-Id: Ie005d5629623a14f4ebd8aef21294f222249232f
Now that the openstack_project::wiki class no longer sets the old,
unused recaptcha parameters, remove them from the module.
Change-Id: I468b4936582701cf308be269bfc06801276efd18
Depends-On: I9f9ba63399a8885e3694cef37ec987f223ff6dca
The newer recaptcha-nocaptcha implementation is a little better at
thwarting script-driven spammers and vandals, so switch to it. Leave
the parameter names for the old recaptcha implementation in place
until our consumer in the openstack_project::wiki class no longer
attempts to set it.
Change-Id: I435484cd65a028d774dfd920ca19f3077d4e03fb
So that we can have non-local (e.g., Trove based) databases, and for
general downstream flexibility, allow the database server hostname,
database name and database username to be passed into this module by
the caller.
Change-Id: I26a03e2ce9a6bf8bcd6acbad9e8eaaa98e0f26ab
Consistent with the vhost template, in Settings.php.erb use the
shorter @ lookups rather than calling the scope.lookupvar()
function.
Change-Id: Ic03dbb55e4931d334a2cf5d4fae6a07cf53dd807
Adjust the SSL/TLS X.509 file handling to match our flexible
standard, which allows the deployer to choose between managing the
contents in or outside Puppet while still providing for a sane
snakeoil fallback to ease testing and development. Also tune the SSL
configuration to our typical stricter defaults, unconditionally
redirect all HTTP requests to HTTPS, and reformat the vhost
configuration for consistency and ease of future maintenance.
Change-Id: Id5241377665845f8c453cbb833bc40d3a5915d76
Since we've already manually upgraded production to Ubuntu Trusty,
let's start with a clean slate for now and just target latest
Mediawiki on a fresh Trusty deployment. This simplifies or removes
some of the conditional logic in this module.
Change-Id: Ia8e74c85667719178c2f50b1458a9719582e8502
Patrolled Edits is a feature on mediawiki that allows marking edits as
"known good" (i.e. ham, as opposed to spam). This can be used to
list edits that have not been assessed, which makes spam easier to
identify and deal with.
Automatic patrolling is where this happens without human intervention.
In our version of mediawiki, there is the ability to have defined users
whose edits are automatically marked as 'patrolled'.
This patch makes a new group, so that bureaucrats of the wiki can
assign "known good" users to this group. The group is given the permission
of 'autopatrol', which means users added to this group will have their
edits automatically marked as 'patrolled'.
Further information about this feature and how to verify the syntax for
this patch is available at:
https://www.mediawiki.org/wiki/Help:Patrolled_editshttps://www.mediawiki.org/wiki/Manual:User_rights
Change-Id: I798f3909bc95fb28c3a0f704fb89a490e10b015f
Now that we have a more robust captcha implemented for page edits,
let's allow general account creation again.
This reverts commit 3dc0d18a1c51bdea4187dfb066cafa0a6cedd4c8.
Change-Id: Ie68d01980c6a96619878d588ee2b4114d6cc6c7a
Once the dependency for this merges to system-config, remove the
unused wg_captchaquestions variable.
Change-Id: If3ac86edc27bda317fe3a29f984dc9a2acd79e31
Depends-On: I0f184c9bfa2bdaaca2478500d8f3b418c9bf77ae
Modified settings file to remove questy captcha and add recaptcha.
Setup two new variables to hold public and private recaptcha keys
wg_recaptchapublickey and wg_recaptchaprivatekey.
Change-Id: Idfa2c01fb9d31f06643d6c82438c33db1ff33009
Order and intendation of those parameters are changed
to follow Puppet Style Guide recommendation [0].
Moreover, it will allow to an user to find much faster
a variable in a list of variables.
[0]. https://docs.puppetlabs.com/guides/style_guide.html
Change-Id: Ifdd5e7de4b4dc9fbd30535720d5674c211985913
The goal here is to allow mediawiki to create an openid user while
leaving the createaccount permission false. According to
documentation[1] this settings should do just that.
We want try and keep createaccount set to false, as this will force
users to use openid.
[1] https://www.mediawiki.org/wiki/Extension:OpenID
Change-Id: Id63a33907f326ddc561ec1049dd1766a7319eb9e
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
The SmiteSpam extension provides a special page "Special:SmiteSpam"
helping administrators identify and delete spam pages.
An infra-root will need to manually download the extension from:
https://www.mediawiki.org/wiki/Extension:SmiteSpam
Change-Id: I018a4c80b77f64353c0163fe8be8dc330b01fc74
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
In an effort to mitigate spamming, we are limiting the files we support
for uploads.
Change-Id: I391da321853e0df3b547882b8dfd6dccf4afd922
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Looking at ListGroupRights[1] users created by OpenID have a different
group to control access. So, new users accounts created outside OpenID
will be disabled, but sysadmins can still manually create them (for
our bots). Everybody else will be forced into OpenID.
[1] https://wiki.openstack.org/wiki/Special:ListGroupRights
Change-Id: I8bb4f0b07c13da75106bfbf725db372ff11dfd09
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
The SpamBlacklist extension prevents edits that contain URLs whose
domains match regular expression patterns defined in specified files
or wiki pages and registration by users using specified email
addresses.
We also need an infra-root to manual download and install the
extension. See below for instructions
https://www.mediawiki.org/wiki/Extension:SpamBlacklist
Change-Id: If752923483c5d7663ed33043f1b799cef2fface0
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Lets enable it for all pages, as spamming is still ongoing.
Change-Id: I7085199143ae28194bc77b3994dcfb84915d4e49
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
In an effort to limit our current spam attack on wiki.o.o we'll be
enabling captcha[1] when a user creates / edits a page.
[1] https://www.mediawiki.org/wiki/Extension:QuestyCaptcha
Change-Id: I33129a5084fa3b3c3e792a61c968f76510bf6078
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
