WordPress.org

Ready to get started?Download WordPress

Forums

Akismet
"Network Status" broken when using proxy server (4 posts)

  1. usrlocaldick
    Member
    Posted 10 months ago #

    Hi

    We're running WP on a host that has no outgoing IP connectivity. For outgoing HTTP traffic we have configured a proxy server in WP.
    Unfortunately the "Server Connectivity" in the admin panel always says "Unable to reach any Akismet servers".
    I've whitelisted the correct domains in the proxy (*.akismet.com and *.rest.akismet.com).
    After some tcpdumping/curling, I found the following.

    akismet_check_server_connectivity() iterates through IP addresses to check reachability.
    The resulting IPv4 addresses are eventually being used by akismet_http_post(), which in turn uses wp_remote_post() if available.
    Because WP uses a proxy, the HTTP requests that are being made look like this:

    http://66.135.58.61/1.1/verify-key

    These literal IP URLs are whitelisted in the proxy server.
    However, I still get "Unable to reach any Akismet servers."
    The Aksimet servers first respond with a 301 (redirect):

    POST http://66.135.58.61/1.1/verify-key HTTP/1.0
    User-Agent: WordPress/3.6.1 | Akismet/2.5.9
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Host: rest.akismet.com
    Accept-Encoding: deflate;q=1.0, compress;q=0.5
    Content-Length: 51
    
    key=aaaaaaaaaaaa&blog=https%3A%2F%2Fblog.refeds.org
    
    HTTP/1.0 301 Moved Permanently
    Server: nginx
    Date: Mon, 07 Oct 2013 13:21:27 GMT
    Content-Type: text/html
    Content-Length: 178
    Location: http://akismet.com/1.1/verify-key
    X-Cache: MISS from proxy.terena.org
    X-Cache-Lookup: MISS from proxy.terena.org:80
    Via: 1.0 proxy.terena.org (squid/3.1.19)
    Connection: close

    Because wp_remote_post() by default follows 5 redirects, the next HTTP request that is done is:

    POST http://akismet.com/1.1/verify-key HTTP/1.0
    User-Agent: WordPress/3.6.1 | Akismet/2.5.9
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Host: rest.akismet.com
    Accept-Encoding: deflate;q=1.0, compress;q=0.5
    Content-Length: 51
    
    key=aaaaaaaaaaaa&blog=https%3A%2F%2Fblog.refeds.org
    
    HTTP/1.0 404 Not Found
    Server: nginx
    Date: Mon, 07 Oct 2013 13:21:27 GMT
    Content-Type: text/html; charset=utf-8
    Vary: Accept-Encoding
    X-Cache: MISS from proxy.terena.org
    X-Cache-Lookup: MISS from proxy.terena.org:80
    Via: 1.0 proxy.terena.org (squid/3.1.19)
    Connection: close
    
    <!DOCTYPE html>
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
    .<meta http-equiv="content-type" content="text/html; charset=utf-8" />
    .<title>404 - Sorry, this page cannot be found - Akismet</title>

    The fundamental problem is that akismet_check_server_connectivity() wants to connect individually to each web server that is listed in DNS, but this is not possible when using a proxy.

    The first attempt with a literal IP address yields a redirect to 'http://akismet.com/1.1/verify-key`.
    The second attempt then fails with a 404. Even if it didn't fail (for instance when Nginx redirected it to 'http://rest.akismet.com/1.1/verify-key'), it would still be a request to a DNS host name, and not to the specific IP address.
    In other words, the IP addresses would be listed as 'green' on the admin page, but the actual checks might have been done on different hosts.

    I see several ways to solve this issue:

    1) Have the Akismet Nginx web servers accept requests for /1.1/verify-key on all 'vhosts' (or whatever they're called - I'm used to Apache), so that stuff like http://66.135.58.61/1.1/verify-key would work. The "Network Connectivity" panel would then work, and display real information.
    Don't know what the consequences are, because apparently the general Akismet web site is run on the same hosts as the key verification web service.

    2) Change the functionality so that the "Network Connectivity" panel doesn't try to iterate over the available IP addresses when there is proxy server configured in WP.

    There might be more options.

    Thanks for looking into this.

  2. algjeff
    Member
    Posted 8 months ago #

    We are having the same issue. I guess we just paid for a broken plugin... will this be addressed at any time soon? Looks like this has been an issue for at least two months.

  3. Mike
    Member
    Posted 3 months ago #

    I've become aware of the same issue since moving to WordPress 3.9.1 and Akismet 3.

    Do you know if the actual spam filtering is affected by the failure to verify the key?

    EDIT. I've hardcoded the $servers array with values = true until this issue is resolved. Not good :(

  4. Jasonheffner
    Member
    Posted 3 months ago #

    The SPAM filtering still seems to be working. We are experiencing the same issue. We were using a patch on the earlier version to work with proxy servers, which isn't needed now since it runs through the WordPress APIs.

    I commented out these lines in class.akismet.php

    // use a specific IP if provided
                    // needed by Akismet_Admin::check_server_connectivity()
                    if ( $ip && long2ip( ip2long( $ip ) ) ) {
                            $http_host = $ip;
                    }

    This will bypass the IP checks, by IP, to check if servers are up. Obviously this breaks that functionality, but I found out why the proxy server isn't working anymore.

    A proxy server generally changes the Host header to preserve the same-origin. This is done to prevent header forgery. The akismet api relies on the host header being "apikey".rest.akismet.com. If it isn't then the akismet api returns a 404.

    Aksimet needs to update their api to accommodate using a web proxy in my opinion. On our end we can spin up a web proxy server just for our WordPress install that doesn't re-write the Host header.

Reply

You must log in to post.

About this Plugin

About this Topic