Have CheckUser scan HTTP user-agent header
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	• bzimport
	Dec 17 2006, 12:28 PM

Description

Author: dodgy

Description:
I think if CheckUser scanned HTTP header "User Agent", it would be even better because User Agent also
includes people's browser, operating system, and what browser extentions (sometimes) they have.

Version: unspecified
Severity: enhancement

Details

Reference: bz8290

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:32 PM

• bzimport added a project: CheckUser.

• bzimport set Reference to bz8290.

• bzimport created this task.Dec 17 2006, 12:28 PM

wiki.pill wrote:

(In reply to comment #0)

I think if CheckUser scanned HTTP header "User Agent", it would be even better

because User Agent also

includes people's browser, operating system, and what browser extentions

(sometimes) they have.

And why should that be helpful?

robchur wrote:

That data isn't stored anywhere, so CheckUser can't actually access it, and
storing it would probably cause a privacy stink.

dodgy wrote:

You can view all your HTTP headers at http://www.ioerror.us/ip/headers

That sort of thing can also detect proxies.

As for User Agent, it's not so much privacy since browsers do report that. A few can alter it, but
most can't and most can't alter the Operating System part. When you email eBay within their website
and they reply, you automatically see your user agent is printed out on one of the lines sent in the
email (for some reason?). MediaWiki software also appears to check that to give the right skin pages.

robchur wrote:

You can also fake a user agent.

ayg wrote:

Which doesn't negate the fact that most people don't know how or it wouldn't
occur to them, so this would remain useful regardless. You can also fake IP
addresses, after all. This seems like a good idea.

robchur wrote:

Fair enough. This will require a schema change to add a column to recentchanges
to store the user agent.

Modifications to MySQL5 tables

attachment httpCUheadTables.patch ignored as obsolete

Patch to add rc_agent to recent changes

Changes to Recentchange.php, minor argument changes to article/logpage.php, new
$wgPutAgentinRC var is defaultsetttings.php

attachment httpheadCU.patch ignored as obsolete

Patch to add HTTP header user agent checking to checkuser

attachment checkuser2.patch ignored as obsolete

Updater maintenance "arhive" stuff

Also a file named "patch-rc_agent.sql" is needed, containing:

Adding the rc_agent field for logging client info in recentchanges

ALTER TABLE /*$wgDBprefix*/recentchanges

ADD rc_agent varchar(255) NOT NULL default '';

attachment updater.patch ignored as obsolete

Summary patch for HTTP header, XFF info, and searching deleted edits

Since header/foward unfo and deleted edit patches change the same areas, its
easier to do both.

rc_agent, rc_xff and rc_archived columns are added to recent changes.

rc_archived is used to hide deleted edits from RC rather than have them deleted
by article.php on page archival. Undeleted entries that are still new will
become visible again (wich they don't currently) as they should.

attachment checkuser2.patch ignored as obsolete

Add sql archive files, minor fixes

attachment checkuser2.patch ignored as obsolete

ChangesList - make archived RC entries wrapped in deleted-rev CSS

This just makes it more clear should deleted edits appear in the results
(checkuser should be the only thing that includes them).

attachment changelist.patch ignored as obsolete

wikt.3.connelm wrote:

Stupid question here: Since you'll be recognizing the XFF information now, will
auto-blocks also use this info? That is, when an AOL user is blocked, will it
be that IP or the XFF that is auto-blocked? (How detailed is the AOL XFF
header, anyway? Just dial-up sessions, or [hashed] AOL username specific?)

wikt.3.connelm wrote:

Oh, and THANK YOU FOR INCLUDING DELETED EDITS! Thank you, thank you, thank you!
May all the blessings of our creator rain down upon you and yours! Wonderful!
Magnificent! Thank you!

Ahem.

That is to say, well done. Bravo.

robchur wrote:

It might be better to combine the User Agent and X-Forwarded-For chain in a
single column in some manner. This would then make it easier to add further data
in the future, for example.

dodgy wrote:

Yes, definitely the X-Forwareded. There's actually several of these ones like X-Originating IP. I
believe there are five.

There'a Bluecoat-Forwarded thing, which is encoded somehow and it looks like ABDD43DEGO. I contacted
the people who make the Bluecoat proxies and they claim it's not encrypted and is decodable, but
would not tell me how (just sent a 100 page manual that also didn't tell me about the encoding).

There are proxies that don't spill the IP but they are much harder to find and a whole lot slower.

anaconda wrote:

Good work, man. I tried it out; two things: please check the timestamp, it's always the same for me (all log entries start with "<li>05:01, 3 January 2007", when I used your patched version for the first time). Also, localize the "Go" button (you
can use MediaWiki:Go for that).

anaconda wrote:

(In reply to comment #18)

Good work, man. I tried it out; two things: please check the timestamp, it's always the same for me (all log entries start with "<li>05:01, 3 January 2007", when I used your patched version for the first time). Also, localize the "Go" button (you
can use MediaWiki:Go for that).

I used it for the first at 04.59 :-). But the bug in this line: $date=date("H:m, j F Y",$timestamp); that should be $date=date("H:i, j F Y",$timestamp);

Summary patch - fix date bug, make radio buttons larger

attachment checkuser2.patch ignored as obsolete

dodgy wrote:

Okay here's some proxy headers:

X-Forwarded-For: 123.123.123.123
Client-ip: 123.123.123.123
Via: 1.0 cache4.jed
X-BlueCoat-Via: 233643FA53757673

dodgy wrote:

Sometimes proxies also have

X-Forwarded-Host:
X-Forwarded-Server:

Summary patch - update

-Secure form some more
-Use XML class stuff to compile some of the form
-Use "bool" to make SQL column type more clear
-Add a class to radio buttons rather than use style, they can be enlarged
locally

attachment checkuser2.patch ignored as obsolete

Alternate patch - seperate checkuser table

This patch adds:
-A streamlined recent changes table for checkuser with its own cut off date. It
also stores the IP as an integer, xff, and user agent data.
-An rc_archived column that is used for exclusion in watchlists/RC ect. Entries
from new edits that where deleted/restored can actually come back now as
article.php and undelete.php just use this flag rather than deleting entries.
-And rc_deleted column for revisiondelete, changelist.php will need some
rewriting later to use it. Revisiondelete needs rc_deleted for proper hiding of
data.
-Improved UI and handling of bad input

Todo maybe:
-All page links from checkuser results are blue linked, even for deleted pages.
Either two delete/restore hooks need to be added or a parameter for
changeslists that allows use of either LinkObj or KnownLinkObj depending on
some argument if this is to be done.