Opened 14 years ago
Closed 13 years ago
#16402 closed defect (bug) (fixed)
IXR client doesn't properly handle XMLRPC over HTTPS
Reported by: | bryanmaupin | Owned by: | westi |
---|---|---|---|
Milestone: | 3.2 | Priority: | normal |
Severity: | major | Version: | 3.0 |
Component: | XML-RPC | Keywords: | has-patch needs-testing |
Focuses: | Cc: |
Description
There are two problems with the IXR XMLRPC client:
- The current IXR client code defaults to port 80, and isn't smart enough to know the port should be 443 if an https URL is sent.
- The IXR client doesn't create an SSL connection even if the port is 443.
I first noticed this because we're using an apache redirect to redirect XMLRPC requests to SSL (except the RSD) to avoid sending passwords in clear text. Some clients (like windows live writer) use the blogger API instead of the wp API for wp sites. For wp multisite, blogger_getUsersBlogs() calls _multisite_getUsersBlogs(), which creates a new IXR XMLRPC client. But _multisite_getUsersBlogs() doesn't send a port number with the URL, so the IXR client defaults to port 80 (problem #1). Even if _multisite_getUsersBlogs() sent a port, the IXR client connection wouldn't be SSL (problem #2).
I'm also going to look into submitting this upstream.
Attachments (3)
Change History (16)
#1
@
14 years ago
WordPress has it's own version of the client: http://core.trac.wordpress.org/browser/trunk/wp-includes/class-wp-http-ixr-client.php that should be used in preference to the IXR_Client base class, as it can handle server configurations and proxy servers better.
Unfortunately, It looks like that may also be affected by this, given it hard codes port 80 if it's not specified.
#3
@
14 years ago
- Keywords has-patch needs-testing added; xmlrpc ssl https removed
@bryanmaupin : could you test the patch I just attached? It modifies WP_HTTP_IXR_Client
instead of IXR_Client
#5
@
14 years ago
- Version changed from 3.1 to 3.0
Moving version to 3.0 as this would not be a regression.
#6
@
13 years ago
There's no need to change the scheme to "ssl://". wp_remote_post()
handles all of that internally when it needs to.
Additionally, we should just let wp_remote_post()
(or the underlying transports) handle the default ports for the given scheme.
Patch attached.
#11
follow-up:
↓ 13
@
13 years ago
- Resolution fixed deleted
- Severity changed from normal to major
- Status changed from closed to reopened
It appears that this issue is still there in WordPress 3.2:
- The XMLRPC-code still uses the IXR-client instead of the WP-HTTP-IXR-Client, so the patch appears to have not been applied.
- Testing WordPress 3.2 in an environment with multi-site and SSL (plus a DMZ that also uses SSL) still fails.
- Replacing IXR-Client with WP-HTTP-IXR-Client still does not get this working.
Please, see also #17541 for additional information.
Michael
#13
in reply to:
↑ 11
@
13 years ago
- Resolution set to fixed
- Status changed from reopened to closed
Replying to Michael_K:
It appears that this issue is still there in WordPress 3.2:
- The XMLRPC-code still uses the IXR-client instead of the WP-HTTP-IXR-Client, so the patch appears to have not been applied.
- Testing WordPress 3.2 in an environment with multi-site and SSL (plus a DMZ that also uses SSL) still fails.
- Replacing IXR-Client with WP-HTTP-IXR-Client still does not get this working.
Please, see also #17541 for additional information.
Lets use #17541 to track this and re-close this ticket.
patch for r17369