The opendev project has been moving away from puppet and this is one of
the puppet modules that is no longer used. To simplify things for us we
are taking the extra step of retiring this repo.
Change-Id: I1e1d3a52022f996e3b28362a6bd97114e494d378
For improved sanitation, have the application write its cache files
in a directory parallel to the Git worktree rather than inside it.
Change-Id: Idcfcf0e3709a03696966aa8c27b897d5be7a1970
To avoid co-mingling configuration-managed files with state data,
place them in parallel paths so that the latter can be mounted from
an external volume.
Change-Id: Ibfedb88bbcf7c816b200b978c987a7c2f3e9f0d4
The EmbedVideo extension referenced in the manifest is no longer
compatible with MediaWiki<1.29.0 so remove it from the active
extensions for now (we can add it back after we move to a newer MW
release).
Change-Id: I8865f143019553062f610c4004147150cff438cd
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
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
To make this module more downstream-friendly, abstract out any
references to OpenStack and turn them into classvars.
Change-Id: Ie005d5629623a14f4ebd8aef21294f222249232f
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
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 3dc0d18a1c.
Change-Id: Ie68d01980c6a96619878d588ee2b4114d6cc6c7a
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
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>
These settings are currently running on wiki.o.o, all we are doing is
adding them into puppet.
Change-Id: I1ad6da353c25aed8976806f00cc39d6c3c93e7ae
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Clark Boylan