Intermediaries that transmit edits in some way sometimes cause problems by MediaWiki seeing their IP instead of the actual editor's. OAuth applications might have this problem. The usual solution is to set X-Forwarded-For headers and whitelist the intermediary IPs for which MediaWiki should trust those headers. This does not work well with intermediaries on some kind of shared hosting (such as Tool Labs). OAuth could offer a superior alternative, where the OAuth consumer identity can be used to decide whether the XFF headers are trustworthy.
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
Tool Labs proxy hides the IP addresses from users. If a tool on tool labs were to send an XFF, what you get would be the IP address of the web proxies, instead of the actual user, from the viewpoint of the gridengine or k8s workers, and I don't think this information is useful at all...
I'd suggest somehow use the data from the time when the user access [[Special:OAuth/authenticate]] (and perhaps mark it so), which is far more reliable than XFF.
Comment Actions
We could probably encrypt that and pass it on if we really wanted to. Probably not worth the effort though.
I'd suggest somehow use the data from the time when the user access [[Special:OAuth/authenticate]] (and perhaps mark it so), which is far more reliable than XFF.
That seems pretty confusing (e.g. for checkusers who see old IPs on new edits without any warning or explanation), plus authorizations can last forever but we cannot store IP addresses indefinitely.
Comment Actions
Note that the OAuth app would have to be thoroughly trusted for this; a malicious app could use fake XSS headers to e.g. test which IP address triggers an autoblock and thus guess the IP of the blocked user. (In the case of Toolforge, the encrypted XFF approach would prevent this.)