* This should avoid duplicate logging events on races or when
the cache fails to update.
* Also added getDBTouched() method to get user_touched itself.
Bug: T48834
Change-Id: Ib2cd0a2c72629fa4e13dcff4d2d6fbac8e690b32
You can add tags at the same time as performing action=edit, as long as you
have the "applychangetags" right. Also, you can add or remove tags after
the fact from revisions and log entries using the API action=tags.
No UI is provided for either of these changes. The target audience is user
scripts, gadgets and similar tools.
Includes a new log parameter format type: "list", for a comma-separated
list of values.
Logging of change tag events is limited to those that do not accompany an
edit (i.e. those done after the fact), and is hidden from Special:Log by
default, similar to the patrol log.
Bug: T20670
Change-Id: I37275e0f73fa3127f55da0c320b892551b61ee80
* This method is used for clearing the User cache as well
as bumping the value of getTouched() for HTTP 304 logic.
These do not need to do the actual user_touched update.
* This also avoids problems with setting mTouched but
deferring the update. That confused the CAS update
logic since it expects mTouched to be in the DB.
Change-Id: I96b30f5c9c8b4714e6663b187f741954a13312cf
* This does not handle race conditions, but is a prelude to using CAS
style logic on save using the timestamp.
Change-Id: I9c31c272fcf77b686764b7c3a6a32ac29576347c
* Ideally saveSettings() would not just silently do nothing in
read-only mode as not all callers expect that behavior. This
change is just the first step.
Change-Id: Ieeaf531dac3027ddba89c60159b98f9c04de78d3
Prevent DoS attacks caused by the amount of time
it takes to hash long passwords by setting a limit
on password length.
Slightly restructures the behavior of User::checkPasswordValidity
in order to accommodate for the difference between
passwords the user should be able to log in with and
passwords they should not.
Bug: T64685
Change-Id: I24f33474c6f934fb8d94bb054dc23093abfebd5e
* Warn when saving slave-loaded data in saveSettings()
* Respect the loading $flags for preferences/groups
* Fixed use of flags in addToDatabase()
* Made loadFromCache() protected to make this mess easier
to reason about (no callers found)
* Added some doc comments
Bug: T92232
Change-Id: Ic1dd66063cc2f98fc03861df1c523981f846a0be
* The loading logic is complex enough without more possible
entry points to cover
* No outside callers found
Change-Id: I7e9bace35afb0a540993423cf1da98381a516ac5
The RESTBase team has requested the ability to check the validity of a
CSRF token and to interface with Title::userCan().
The former is accomplished by the new action=checktoken module. The
latter by a new parameter ('testactions') to the existing prop=info.
Bug: T88010
Change-Id: I2530f1315ec93f5be9fb437137992150fdc305f2
This change has not been advertised and cause random extensions
to start failing giving little clue to users.
Please have this change discussed on wikitech-l and announced
ahead of time to minimize disruptions. It brokes MathSearch at least:
https://gerrit.wikimedia.org/r/#/c/189442/
This reverts commit d333cd8f7b.
Change-Id: If9a28b1386fca946d8ba351c16134cdf7da8a148
Because extensions often don't add their rights to $wgAvailableRights
or via the 'UserGetAllRights' hook, thus User::getAllRights is incomplete.
Change-Id: Id9ae9eff71e822ec5c038c1c1f990ac36f05cea8
This allows users with the `managechangetags` right to create tags for
use by wiki users. (Currently there is no way for editors to apply tags
to their edits; that's to come in a later patch.)
Extensions can reserve tag names for their own use, even if they do not
define them or mark them as active.
Tag managers can also delete tags with <= 5000 uses. Currently, if a tag is
misspelt ("vandlaism") or no longer wanted (testing of OAuth, etc), the
wiki is stuck with it forever. This change allows users with the
"managechangetags" right to delete change tags from the database,
including removing them from all revisions to which they are applied.
Obviously this is a powerful thing to be able to do, but I view change
tags as a "light" kind of interface, useful for revision patrolling and
spam/vandalism fighting but not something that necessarily needs to hang
around forever. It's not a big deal for this kind of data to be thrown
away without being archived anywhere.
Tags defined by an extension can only be deleted if the extension allows
it.
Changes to tags are logged in the new "tag management" log. There's even
a nice API module, just for fun.
Bug: T20670
Change-Id: I77f476c8d0f32c80f720aa2c5e66869c81faa282
Have User::addGroup() and User::removeGroup() methoids return a
boolean when their respective hooks return the respective boolean.
Fix SpecialUserrights to respect this return vale and update the
add/remove arrays accordingly.
This resolves an issue where a hook that prevents a group from
being added or removed still shows that group being changed in
the Userrights log.
Change-Id: I7621cc22b04ff41cf67bd434a1f89d31bdc2cffd
Seems stupid omission. Title has one. Why do I need to think how
to determine how to users objects point to the same user. Allows
more expressive code.
Also fixes a bug in multiple places where users "0" and "00" were
considered equal.
Change-Id: I682392e564b332b77ab489f2ad394fa2d28098a5
Xhprof generates this data now. Custom profiling of various
sub-function units are kept.
Calls to profiler represented about 3% of page execution
time on Special:BlankPage (1.5% in/out); after this change
it's down to about 0.98% of page execution time.
Change-Id: Id9a1dc9d8f80bbd52e42226b724a1e1213d07af7
We currently embed the full set of user options in a <script> tag in the HTML
output of every page. This is grossly inefficient, because the full set of
options is usually largely made up of site defaults which the user hasn't
customized.
So instead of doing that, let's emit the default options using one
ResourceLoader module and then apply the user's customizations on top.
This has the effect of slightly increasing the total bytes of JavaScript code
(because options that the user has customized will be emitted twice: once with
their default value in the user.defaults module, and then again with the
customized value in user.options). But this is more than offset by the
fact that the bulk of user options code (~4 kB uncompressed on enwiki) becomes
cacheable across requests.
Bonus round:
* Varnish gets to cache 4 kB fewer per page.
* Changes to the default options don't take 30 days to propagate.
Change-Id: I5a7e258d2d69159381bf5cc363227088b8fd6019
When calling User::setCookies with a $request object that was not
passed on to the User::setCookie method, which went ahead and
updated the request from RequestContext::getMain rather than
the provided request.
This patch adds another parameter to User::setCookie to accept
a request object, and User::setCookies to pass the request along.
Change-Id: Ie46fd8c90753e8bf54ce58842c08e0519a269582
