Why:
* Echo stores agents by their user id or by the name if the user
is not registered. This works for IPs since the "event_agent_ip"
field has limit of 39 bytes (32× [0-9A-F] + 7× colon for IPv6).
* However, it's possible to hold a user identity that is not
an IP address, but the user name has not been or cannot be
registered (e.g., external users). Echo wouldn't validate this
and would attempt to insert the user name into "event_agent_ip",
possibly causing silent truncation and data corruption.
What:
* Do not let events with such agents be saved. For now, log an
error in the production. Wikibase, the only known source of this
problem, has already been fixed.
* In runtime, replace every possibly corrupted user name with
a placeholder to avoid unexpected null values and exceptions
in production.
Bug: T367638
Change-Id: Ic2bd218b10651d13da9e9aea54dd2d668a33d946
Depends-On: I03b4367355dc5a3fc0c14aad5fdf19fbcd0caa3d
Depends-On: I92eb93983e81708b289e9f7d837884d539dade0b
Why:
* On wikis with lots of bot activity like Wikidata, there is a large
volume of edits which can potentially create an article-linked
notification. These notifications are now actually rarely sent
because they are disabled for bots (T318523). However, the event
record is always inserted into the database, with no reference to
it, bloating the database.
What:
* Do not unconditionally insert an event into the database when
Event::create is called. Pass it to downstream calls and have
it inserted when it's clear it will actually be needed (i.e.,
a notification is definitely going to be created).
* Pass the event's payload to the job queue instead of requiring
its ID. Introduce Event::newFromArray, which unlike ::loadFromRow
handles ::toDbArray values that haven't been inserted into
the database yet.
* Introduce Event::acquireId which ensures the event has been
inserted prior to returning its ID as well as it does not get
re-inserted.
Bug: T221258
Change-Id: I8b9a99a197d6af2845d85d9e35c6703640f70b91
There is no guarantee the MediaWikiServices instance is still valid.
Other tests can reset it.
Bug: T368390
Change-Id: I92de60b2ba5fb66af957a800ce85773db58303cc
Deprecated in T342301 in v1.41. This is now tracked
automatically. The variable can be safely deleted.
Change-Id: I3864ee85e8b0ff74385eee88018a37f61927f5ef
Changes to the use statements done automatically via script
Addition of missing use statements done manually
Change-Id: Iad87245bf8082193be72f7e482f29e9f1bad11fc
Use
$this->getServiceContainer()
instead of
MediaWikiServices::getInstance()
in maintenance and tests.
Change-Id: I845e8f083b19da093166d6551683f2013eec7bb1
Use mocks when possible, and add the test to the Database group
otherwise.
Also rename 2 test files to avoid a PHPUnit deprecation of file name not
matching class name.
Change-Id: I16b2392daf01f63511c82b4ed0e67a38e35ddbe1
Notably: any() is the default anyway. It doesn't really make the
tests more specific or better readable when we repeat it all the
time.
Change-Id: I56d201bfce454587b00015b7208f313dd8ed9624
Replace User::getOption() with UserOptionsLookup::getOption() since this method will be hard-deprecated.
Bug: T296083
Change-Id: I0ecdc63b0344bc4c24196cc5edb3d02b6a7ed615
At the moment we support a maximum of 10 tokens per user for subscribing
to push notifications, stored as a basic list that runs out when the
limit is reached. There may, however, be some edge cases where an app
registers a token and then forgets to unregister it (and repeats this 10
times), after which time it will be unable to register any new token.
This changes the token list to behave more like a circular buffer, by
simply deleting the oldest token before inserting the new one. This way
an app could register a new token even in the rare case of forgetting
the previous ten.
Change-Id: I387de63460882e4e56d1aa6db1f78d73a0495208
Adds AttributeManager to EchoServices so that dependencies of
AttributeManager can be injected.
Bug: T275148
Change-Id: I4fa5084d72914d16b6d218e7dd3521f5a1919b80
Use the mock HTTP request, in preparation for I1702c11928f87
Depends-On: I8ce17da7315b87b8dd0e502e601b9ac488089456
Needed-By: I1702c11928f8760bb41b41f4c7c04d7af03f62e2
Bug: T262443
Change-Id: I390856b4609635cee22253071f21ce63ff716791
Creates a new push-subscription-manager group and an associated
right, manage-all-push-subscriptions. The purpose of this is to
allow privileged accounts to purge expired subscriptions from the
database on behalf of other users. A user with this right will be
permitted to delete any subscription from the DB based on the token
alone. For all other users, deletion requests will be limited to
those associated with the requesting user's central ID.
This right will be granted to a bot account on Metawiki associated
with the Wikimedia push notifications service, and the push
notifications service account will make push subscription delete
requests to the API for subscriptions for which vendor APIs return bad
subscription responses.
Additionally, the providertoken parameter to ApiPushSubscriptionDelete
is updated to allow multiple providertoken values.
Bug: T259148
Change-Id: Ia6c17588ee94e6be74e5e3a75eb33e38f172fc93
Creates a EchoPushMaxSubscriptionsPerUser config setting (default: 0)
that controls the maximum number of subscriptions a user may associate
with the user's central user ID.
The setting is enforced in EchoPush\SubscriptionManager::create().
To allow creating push subscriptions for development, set
$wgEchoPushMaxSubscriptionsPerUser to a positive integer value in
LocalSettings.php:
$wgEchoPushMaxSubscriptionsPerUser = 10;
Bug: T259150
Change-Id: Ib97b6b6cbb8161dd75dad92c54b4fe4fff80c421
Adds additional job parameters to help diagnose the apparent issue of
jobs being performed twice on Beta.
Bug: T255068
Change-Id: Ib257a24056539487e1110fe286fa4535c3fec94a
Finishes the implementation of the stubbed NotificationServiceClient.
Sends push notification request messages to the endpoint configured in
the EchoPushServiceBaseUrl setting. For example, to send messages to an
instance of mediawiki/services/push-notifications running on the host
machine while running MediaWiki in Docker, add the following line to
LocalSettings.php:
$wgEchoPushServiceBaseUrl = 'http://172.17.0.1:8900/v1/message';
Bug: T252899
Change-Id: Icab7825e9080d6b1a4cfc5e12fed1da221ce4610
Provides a basic push notifier implementation. Since the push service is
not yet in place, all it does for now is log debug output when a
notification is to be sent.
To register the push notifier, add the following configuration to
LocalSettings.php:
$wgEchoNotifiers['push'] = [ 'EchoPush\\PushNotifier', 'notifyWithPush' ];
$wgDefaultNotifyTypeAvailability['push'] = true;
$wgNotifyTypeAvailabilityByCategory['system']['push'] = false;
$wgNotifyTypeAvailabilityByCategory['system-noemail']['push'] = false;
We'll register the notifier in configuration for now, rather than
hard-coding the default in extension.json, in order to have control over
when and where it rolls out (beta vs. prod, as well as which wikis).
Since the push notifier implementation depends on jobs being processed
by the job queue, I also recommend adding the following configuration
setting to ensure that all pending jobs are processed at the end of each
web request:
// ensure all pending jobs are processed when a web request completes
$wgJobRunRate = PHP_INT_MAX;
Bug: T252899
Change-Id: Ie7f222443045d30620ff297b006104ef18a074a8
Adds DB tables for storing push subscriptions, some DB interaction code
for retrieving them within MediaWiki, and a set of API modules for
managing them from the outside world.
When testing this patch, be sure to run maintenance/update.php to create
the new tables, and set $wgEchoEnablePush = true in LocalSettings.php
to enable the API new API module.
N.B. The current DB schema is centered on app push subscriptions. Web
push subscriptions require slightly different handling, since they are
provided by browsers as a JSON blob rather than a token string. How to
handle web push subscriptions is a question we can defer until the time
comes to add web push support.
Subscription data is stored in the echo_push_subscription table, with
provider names normalized into the echo_push_provider table. We expect to
be looking up subscriptions by central user ID, so that column is indexed.
The subscription data also includes a column to store SHA256 digests of
the subscriber tokens. This is for use as a unique key constraint, since
we expect every push token to be univerally unique, and the token values
themselves may be too large to reasonably index in MySQL.
Bug: T252899
Change-Id: I3928761b3fba12e54ff4850e9a05c68ec7772f62
