Hi Everyone,
I was looking at our Special:Version page, and got to thinking about
api.php [1] and rest.php.[2] I don't believe anyone on our team is
using the APIs, and I would like to disable them to reduce attack
surface. Or disable them on external interfaces (or maybe allow on
localhost/127.0.0.1).
I see api.php can be disabled via $wgEnableAPI.[1] But I don't see a
similar option for rest.php.[2]
I have two questions. First, is it possible to disable api.php and
rest.php in practice? Or restrict them to internal interfaces only?
Second, what option controls rest.php?
And maybe a third question, can we rename api.php and rest.php tosay,
api.php.unused and rest.php.unused? Will that produce ill effects?
Thanks in advance.
[1] https://www.mediawiki.org/wiki/Manual:Api.php
[2] https://www.mediawiki.org/wiki/Manual:Rest.php
I have a few inactive MediaWiki sites currently running 1.26.4 that I want
to convert to static HTML. As a first step, I enabled short URLs using
the instructions at https://www.mediawiki.org/wiki/Manual:Short_URL/Apache
. The site I am working on was originally in https://example.ca/dm. I
moved the 'dm' folder to 'w'. In the root folder, I added the following
line to .htaccess in the document root which contains both the 'w' and
'dm' folders.
RewriteRule ^/?dm(/.*)?$ %{DOCUMENT_ROOT}/w/index.php [L]
The site loaded fine when accessed as https://example.ca/w. I then
updated LocalSettings.php using 'dm' as a replacement for 'wiki':
$wgScriptPath = "/w";
$wgArticlePath = "/dm/$1";
I purged the cache by truncating the MySQL objectcache. When I access
https://example.ca/dm, the site appears to load properly. However, I
noticed a lot of references to /w:
<link rel="stylesheet"
href="/w/load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.sectionAnchor%7Cmediawiki.skinning.interface%7Cskins.vector.styles&only=styles&skin=vector"
/>
<script async
src="/w/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector"></script>
There are other references to /w and //example.ca/w for links such as
'edit', 'search', and 'talk' but those will be deleted anyway.
I downloaded the site using wget and the instructions at
http://camwebb.info/blog/2012-12-20/. When I uploaded the static HTML
files to a web server and displayed the first page, it lacked stylesheets
- they had been downloaded to a 'w' folder as:
load.php?debug=false&lang=en&modules=mediawiki.action.view.filepage%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.sectionAnchor%7Cmediawiki.skinning.content.externallinks%7Cmediawiki.skinning.interface%7Cskins.monobook.styles&only
The browser failed with a 404 when trying to access the following in the
static index.html:
<link rel="stylesheet"
href="../w/load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%252Cshared%257Cmediawiki.sectionAnchor%257Cmediawiki.skinning.content.externallinks%257Cmediawiki.skinning.interface%257Cskins.monobook.styles&only=styles&skin=monobook"
/>
I tried renaming the various "load.php?..." files to "load.html" and
"load2.html", then updating index.html to point to them. The loadx.html
files load successfully but there is another load.php reference that I
have not found yet, and lots in the other wiki pages.
Am I missing something obvious? I found additional .htaccess Rewrite
rules in
https://www.mediawiki.org/wiki/Manual:Short_URL/wiki/Page_Title_--_.htaccess
but these appear apply if I am trying to run the wiki from
https://example.ca.
the mediawiki team has already reduced attack surface by making the sw less
functional, less fun, and basically broken so what is the difference?
practically none - some other upstart sw will take their place and engage
the cia triad with more efficiency and adroitness so api functions are
largely irrelevant in the longer term, sort of like ozzy osbourne and tony
bourdain. MW had a good run, perhaps they can regain some degree of
functionality that was lost in last few updates but the future is
unwritten.
On Thu, Aug 24, 2023 at 8:03 AM <mediawiki-l-request(a)lists.wikimedia.org>
wrote:
> Send MediaWiki-l mailing list submissions to
> mediawiki-l(a)lists.wikimedia.org
>
> To subscribe or unsubscribe, please visit
>
> https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/
>
> You can reach the person managing the list at
> mediawiki-l-owner(a)lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MediaWiki-l digest..."
>
> Today's Topics:
>
> 1. Disable api.php and rest.php? (Jeffrey Walton)
> 2. Re: Disable api.php and rest.php? (Amir Sarabadani)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 23 Aug 2023 17:13:49 -0400
> From: Jeffrey Walton <noloader(a)gmail.com>
> Subject: [MediaWiki-l] Disable api.php and rest.php?
> To: MediaWiki announcements and site admin list
> <mediawiki-l(a)lists.wikimedia.org>
> Message-ID:
> <
> CAH8yC8nLtkGYhP7dnXpo-hMvnND2Nht66v+UKoanBZSQ-37LXQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Everyone,
>
> I was looking at our Special:Version page, and got to thinking about
> api.php [1] and rest.php.[2] I don't believe anyone on our team is
> using the APIs, and I would like to disable them to reduce attack
> surface. Or disable them on external interfaces (or maybe allow on
> localhost/127.0.0.1).
>
> I see api.php can be disabled via $wgEnableAPI.[1] But I don't see a
> similar option for rest.php.[2]
>
> I have two questions. First, is it possible to disable api.php and
> rest.php in practice? Or restrict them to internal interfaces only?
>
> Second, what option controls rest.php?
>
> And maybe a third question, can we rename api.php and rest.php tosay,
> api.php.unused and rest.php.unused? Will that produce ill effects?
>
> Thanks in advance.
>
> [1] https://www.mediawiki.org/wiki/Manual:Api.php
> [2] https://www.mediawiki.org/wiki/Manual:Rest.php
>
> ------------------------------
>
> Message: 2
> Date: Thu, 24 Aug 2023 04:15:44 +0200
> From: Amir Sarabadani <ladsgroup(a)gmail.com>
> Subject: [MediaWiki-l] Re: Disable api.php and rest.php?
> To: noloader(a)gmail.com, MediaWiki announcements and site admin list
> <mediawiki-l(a)lists.wikimedia.org>
> Message-ID:
> <CA+ttme1kSV34WZb=oAuqba1mvbCOyjnR6_bre=
> TMRGMkxhYNaw(a)mail.gmail.com>
> Content-Type: multipart/alternative;
> boundary="0000000000006298f80603a1d0dc"
>
> You could technically decline access in apache (or whatever software you're
> using).
>
> But I need to warn: Many functionalities of mediawiki are done by calling
> the API in the backend, e.g. when you log out, it calls an API, when you
> watch a page, it calls another API, and all of those would break if you
> disable the api.php or rest.php
>
> HTH
>
> Am Mi., 23. Aug. 2023 um 23:14 Uhr schrieb Jeffrey Walton <
> noloader(a)gmail.com>:
>
> > Hi Everyone,
> >
> > I was looking at our Special:Version page, and got to thinking about
> > api.php [1] and rest.php.[2] I don't believe anyone on our team is
> > using the APIs, and I would like to disable them to reduce attack
> > surface. Or disable them on external interfaces (or maybe allow on
> > localhost/127.0.0.1).
> >
> > I see api.php can be disabled via $wgEnableAPI.[1] But I don't see a
> > similar option for rest.php.[2]
> >
> > I have two questions. First, is it possible to disable api.php and
> > rest.php in practice? Or restrict them to internal interfaces only?
> >
> > Second, what option controls rest.php?
> >
> > And maybe a third question, can we rename api.php and rest.php tosay,
> > api.php.unused and rest.php.unused? Will that produce ill effects?
> >
> > Thanks in advance.
> >
> > [1] https://www.mediawiki.org/wiki/Manual:Api.php
> > [2] https://www.mediawiki.org/wiki/Manual:Rest.php
> > _______________________________________________
> > MediaWiki-l mailing list -- mediawiki-l(a)lists.wikimedia.org
> > To unsubscribe send an email to mediawiki-l-leave(a)lists.wikimedia.org
> >
> >
> https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/
> >
>
>
> --
> Amir (he/him)
>
Hello All,
Following up from conversations at the Wikimedia Hackathon in May
<https://phabricator.wikimedia.org/T336990>, I’d like to give an update on
how we’re approaching the work around MediaWiki and what to expect in the
upcoming months!
Since the beginning of July, the Foundation has dedicated MediaWiki product
leadership and a new MediaWiki engineering group
<https://www.mediawiki.org/wiki/MediaWiki_Engineering_Group>. We’re in the
process of onboarding (i.e. team processes, scope and operational
questions, getting familiar with the domain), have been spreading out to
help with specific projects as consultants and/or code contributors and are
now kicking off broader research to inform a strategy for MediaWiki. This
email is the first edition of a monthly email report to wikitech-l and
mediawiki-l. Reports can also be found on
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports>this page
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports>.
The first 12 months are about building out the foundations for the
following years:
- Building up the new MW Engineering group and MW Product function
{{doing}}
- Developing a strategy for MediaWiki - by June 30th, 2024 [Wikimedia
Foundation Annual Plan, WE3
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/…>]
{{kicking off}}
- Reaching a 20% increase of authors to selected MediaWiki repositories
deployed in Wikimedia production - by June 30th, 2024 [WE3.2] {{preparing}}
- Investing in developer experiences and reduce fragmentation of
developer workflows - continuous work with specific deliverables in 2023/24
[WE 3.1] {{doing}}
- Exploring and resolving a set of questions around stewardship and Open
Source strategy (goes beyond MediaWiki) [WE3.3] {{preparing}}
The approach that we’re trying to take is to work problem-focused (start
from the problem, usage and needs), data driven (conduct research to inform
decisions), step by step (prioritize and scope things, since we can’t
address all questions at once), and take people along (share regularly
about the work, initiate exchange and invite people in).
The research to inform this work
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights> consists of
multiple pillars and phases:
- MediaWiki within Wikimedia’s ecosystem: Key challenges and
opportunities. Includes interviews and review of existing write-ups
(pre-kick off at the Hackathon in May, continue in July)
- MediaWiki usage and development beyond Wikimedia: Synergy effects,
opportunities and challenges (start in November)
- Components-workflow mapping exercise. How are core workflows such as
edit or patrol powered and enabled by MW core components, extensions,
modules, gadgets, tools as of today? Initial focus is on prototyping this
for 1-2 Wikipedias and potentially Wikidata (start in September)
- Exploration of MW platform designs - what changes could we make to
increase the sustainability of the platform, better serve our core
workflows and needs and provide easier, faster and cohesive paths to
feature development? (October-June)
- Ways to establish effective and responsible stewardship for the
platform (October-June)
MediaWiki within Wikimedia’s ecosystem: Interviews
A key part of research is talking to folks. We’ve kicked this off with
first interviews with MediaWiki developers
<https://phabricator.wikimedia.org/T336990> at the Hackathon in May, have
surveyed ourselves (= MediaWiki Engineering group) and plan to conduct more
interviews with a cross-section of people over the next 6 weeks. The main
focus of this round is on MediaWiki within Wikimedia’s ecosystem and we’ll
be reaching out to a few more MediaWiki volunteer developers starting this
week. We’re planning to organize broader MediaWiki ecosystem conversations
in the upcoming quarters.
Project snapshot: Onboarding via Code Mob
As we’re building up the new MediaWiki Engineering Group, we’re also
investing in onboarding team members to MediaWiki development and MediaWiki
APIs who are just getting started. Bill Pirkle has come up with an
onboarding concept and is hosting weekly “Code Mob” sessions for folks on
the teams across MW Engineering - if you’re interested in “learning along”,
you can find a list of recordings and topics on this page
<https://meta.wikimedia.org/wiki/User:BPirkle_(WMF)/Code_Mobs_2023>.
Reporting and documentation
We will share about our work through the monthly emails and in 3-4
MediaWiki Product Insights reports published throughout the Foundations’
fiscal year (July-June). Over the next weeks, we will also create or update
team pages and clean up + create Phabricator workboards to make it easier
to follow along (and for us to keep track/focus :-).
Your ideas, support, patience as we’re settling in, experiences and
insights in challenges and opportunities really matter for this to work
out. A big thanks to all the folks who already have offered support, shared
their experiences, or otherwise helped out so far! <3
If you have specific questions or thoughts on this edition, this talk page
<https://www.mediawiki.org/wiki/Talk:MediaWiki_Product_Insights> is a good
place to connect :-)
Thanks all for reading!
Birgit
--
Birgit Müller (she/her)
Director of Product, MediaWiki and Developer Experiences
Wikimedia Foundation <https://wikimediafoundation.org/>
I was excited a while back to upgrade our wiki to a more recent version
specifically because of the "Special:NewPages" feature. However, now that
I'm using it, I find it doesn't quite do what I thought.
See it in action here:
https://catwiki.xula.edu/Special:NewPages
Currently it's listing three new pages. Why only three? There seems to be a
time limit. Maybe 100 days? That's my guess.
I've consulted the help page:
https://www.mediawiki.org/wiki/Help:New_pages
However, it doesn't mention a time limit.
Does anyone know if there is, indeed, a time limit, and if so what it
might be? Also, is there any hack to get around it?
I'd like to see new pages for the last twelve months or so.
Bart