WordPress.org

Making WordPress.org

Changes between Version 1 and Version 2 of Ticket #2823, comment 13


Ignore:
Timestamp:
05/13/2017 04:18:23 AM (4 years ago)
Author:
dd32
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #2823, comment 13

    v1 v2  
    11> The first problem to solve is #2. I don't think we really need ipv6 support yet since the API should always use REMOTE_ADDR and the WordPress.org API currently doesn't have any AAAA records.
    22
    3 The IP is not the REMOTE_ADDR in most cases - it's the WordPress user client IP, not the server IP. There's some "anonymisation" stuff in there ([see maybe_anonymize_ip_address: https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-community-events.php#L231]). The exception is when the client IP provided is a private range, in which case it uses REMOTE_ADDR.
     3The IP is not the REMOTE_ADDR in most cases - it's the WordPress user client IP, not the server IP. There's some "anonymisation" stuff in there - [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-community-events.php#L231 see maybe_anonymize_ip_address()]. The exception is when the client IP provided is a private range, in which case it uses REMOTE_ADDR.
    44
    55Would it be better if the client browser was making the request directly? (and not proxied through WordPress) - the detect-location call would need to be made on every request in that case, and not just on the first call / when user searches for a location change.