WordPress.org

Forums

WP Slimstat
[resolved] Still problems with IP obfuscation on my 32-bit server (7 posts)

  1. carbeck
    Member
    Posted 1 year ago #

    I'm sorry if this is annoying you, but the IP obfuscation setting still doesn't work correctly on my 32-bit server. What happens is that the original IP will be stored as the secondary IP. What is displayed in the user interface of the plugin is thus:

    123.45.67.0 (Originating IP: 123.45.67.89)

    On the database backend side, the access is logged in wp_slim_stats as:

    ip = 2066563840
    other_ip = 2066563929

    whereas this information should be saved as:

    ip = 2066563840
    other_ip = 0

    So if I want to conform to EU privacy regulations, I have to execute this code manually:

    UPDATE my_database.wp_slim_stats SET other_ip = 0 WHERE ip = other_ip & 4294967040

    https://wordpress.org/plugins/wp-slimstat/

  2. camu
    Member
    Plugin Author

    Posted 1 year ago #

    Are you using our Firewall Fix add-on?

  3. carbeck
    Member
    Posted 1 year ago #

    Nope. But as I already said in our conversation about this in December (when activated IP obfuscation changed all IPs to 127.255.255.0), it all worked fine in the past (before SlimStat 3.7.1) and I'm not aware of any major changes regarding firewalls and load-balancers in my host's server setup. With subsequent updates of SlimStat, IP obfuscation at least works now as outlined in my post above.

    As far as I see it, SlimStat doesn't recognize that the original IP and the same IP filtered through the bitmask are the same, i.e. it's probably more a math related bug than due to my host's firewall settings. Back in December it sounded like there were issues with the differences between a 32-bit and a 64-bit system's handling of (un)signed integers, which is also why I specified that in the title of this thread.

  4. carbeck
    Member
    Posted 1 year ago #

    Also, I wrote a little PHP script (http://pastebin.com/Qbg89Aek) to test the $_SERVER vars that SlimStat reads to determine a user's IP, and reusing the fake IP example from above analogous to my own IP, the result was:

    REMOTE_ADDR:
    sprintf %s: 123.45.67.89 (ip2long %s = 2066563929)
    sprintf %u: 123 (ip2long %u = 2066563929)
    
    HTTP_CLIENT_IP:
    sprintf %s: (ip2long %s = )
    sprintf %u: 0 (ip2long %u = 0)
    
    HTTP_FORWARDED:
    sprintf %s: (ip2long %s = )
    sprintf %u: 0 (ip2long %u = 0)
    
    HTTP_X_FORWARDED_FOR
    sprintf %s: 123.45.67.89 (ip2long %s = 2066563929)
    sprintf %u: 123 (ip2long %u = 2066563929)

    I don't know if that helps in illustrating whether the reason the math goes wrong is due to being behind a firewall or something.

  5. camu
    Member
    Plugin Author

    Posted 1 year ago #

    We're looking into it. Thank you.

  6. camu
    Member
    Plugin Author

    Posted 1 year ago #

    Fixed in 3.5.6.

  7. carbeck
    Member
    Posted 1 year ago #

    Cool. Thanks for looking into it.

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic

Tags

No tags yet.