api.php?action=unblock returns the full user object
Closed, ResolvedPublic
Actions

Assigned To

None

Authored By

	Krenair
	Dec 30 2012, 1:13 PM

Description

When you unblock someone via the API, you get the full user object back. This includes mPassword (hashed, so I'm not sure how much of a big deal this is), mToken, mEmail (not public info), and some other things.

On a slightly unrelated note, I'm not sure api.php?meta=userinfo should return the watchlisttoken preference... In the UI it says 'Filling in this field with a secret key will generate an RSS feed for your watchlist. Anyone who knows the key in this field will be able to read your watchlist, so choose a secure value.'

Version: 1.20.x
Severity: normal

Details

Reference: bz43518

Related Objects

Mentioned In: T47716: Password hashes should not be stored in live User objects
T88397: redirecttitle in API:Search returns title object instead of text

Event Timeline

• bzimport raised the priority of this task from to High.Nov 22 2014, 1:12 AM

• bzimport added projects: MW-1.20-release, MediaWiki-Action-API.

• bzimport set Reference to bz43518.

• bzimport added a subscriber: Unknown Object (MLST).

Krenair created this task.Dec 30 2012, 1:13 PM

(In reply to comment #0)

On a slightly unrelated note, I'm not sure api.php?meta=userinfo should
return
the watchlisttoken preference... In the UI it says 'Filling in this field
with
a secret key will generate an RSS feed for your watchlist. Anyone who knows
the
key in this field will be able to read your watchlist, so choose a secure
value.'

Ignore this bit. meta=userinfo is for the current user only.

Created attachment 11567
Patch

attachment 0001-bug-43518-API-action-unblock-should-return-the-user-.patch ignored as obsolete

This was caused by r83855.

Interesting that __toString() doesn't seem to be working.

The API uses json_encode (When using format=json, obviously. This bug probably doesn't apply to other formats), which doesn't appear to use __toString() (Why represent it as a string when we know about objects?).

<?php
class A {
public $youshouldnotseethis = "uh oh";

function __toString() {

		return "works";

}
}
echo( json_encode( new A() ) );

{"youshouldnotseethis":"uh oh"}

Patch looks reasonable to me, and looks like it should apply fine to both master and 1.20.

We'll get the cluster patched asap, and this will be in the 1.20.3 release.

With this, and admin could easily block and unblock a user to get their password hash, and attempt to escalate their privileges. And if they escalated to someone with suppress rights, they could cover their tracks. So I think this may drive getting 1.20.3 out a little sooner.

Should 1.19 also get this?

Yes, 1.19 should also get this. Shooting for a 1.20.3/1.19.4 release next week.

Reviewing this for release and realized this throws an exception if the block was an autoblock -- "Fatal error: Call to a member function getName() on a non-object".

Probably just need a $target instanceof User ? conditional.

Created attachment 11796
Updated Patch

Attached:

wmf10.patch1 KBDownload

Created attachment 11797
patch for 1.19 branch

Attached:

REL_119.patch1 KBDownload

Can I get someone on this bug to "+2" the attached "Updated Patch", and I'll deploy it to cluster? It's a one line change to includes/api/ApiUnblock.php.

(In reply to comment #10)