Last modified: 2013-12-10 14:03:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 37971 - No results on CheckUser query from 127.0.0.1 on PostgreSQL
No results on CheckUser query from 127.0.0.1 on PostgreSQL
Status: PATCH_TO_REVIEW
Product: MediaWiki extensions
Classification: Unclassified
CheckUser (Other open bugs)
master
All All
: Normal normal (vote)
: ---
Assigned To: OverlordQ
:
Depends on:
Blocks: user-127.0.0.1
  Show dependency treegraph
 
Reported: 2012-06-26 21:00 UTC by Marcin Cieślak
Modified: 2013-12-10 14:03 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Marcin Cieślak 2012-06-26 21:00:20 UTC
When asked for username IP addresses or edits CheckUser might return entries for 127.0.0.1 (for internally generated entries via FauxRequest etc.).

When asked for users on 127.0.0.1 no results are shown, however. 

select * from cu_changes where cuc_ip_hex = '7F000001';

returns no results

It seems like 127.0.0.1 entries are stored like this:


# select * from cu_changes where cuc_ip_hex='0' 
;
-[ RECORD 1 ]--+--------------------------------
cuc_id         | 68
cuc_namespace  | 90
cuc_title      | Dyskusja_użytkownika:Saper/test
cuc_user       | 1
cuc_user_text  | Saper
cuc_actiontext | 
cuc_comment    | Nowy wątek – test
cuc_minor      | 1
cuc_page_id    | 1717
cuc_this_oldid | 63082
cuc_last_oldid | 0
cuc_type       | 1
cuc_timestamp  | 2012-05-07 23:21:58+02
cuc_ip         | 127.0.0.1/32
cuc_ip_hex     | 0
cuc_xff        | 
cuc_xff_hex    | 
cuc_agent      | 

and have cuc_ip_hex stored as zero instead of 7F0001

For MySQL 127.0.0.1 entries are correct:

        cuc_id: 22
 cuc_namespace: 4
     cuc_title: Książki/Moja_książka
      cuc_user: 1
 cuc_user_text: Saper
cuc_actiontext: 
   cuc_comment: Utworzył nową stronę „{{zapisane_książki}}  == Moja książka == === test === :[[Strona główna]]  [[Kategoria:Książki|Książki/Moja książka]]”
     cuc_minor: 0
   cuc_page_id: 8
cuc_this_oldid: 15
cuc_last_oldid: 0
      cuc_type: 1
 cuc_timestamp: 20120301052308
        cuc_ip: 127.0.0.1
    cuc_ip_hex: 7F000001
       cuc_xff: 
   cuc_xff_hex: NULL
     cuc_agent: 
4 rows in set (0.00 sec)
Comment 1 OverlordQ 2012-07-03 15:53:58 UTC
If I had to hazard a guess it's because toHex/toUnsigned in the IP class isn't stripping off the prefix size before passing it to ip2long, which then returns false and there's no error checking.
Comment 2 Marcin Cieślak 2012-07-03 15:56:55 UTC
Yes, looks something like that. What wonders me is why other IPv4 addresses work :)
Comment 3 OverlordQ 2012-07-03 16:21:44 UTC
Meh, my first commit in a while, pushed to gerrit.

https://gerrit.wikimedia.org/r/14068

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links