https atom service document doesn't point to https collections

[rubys]

It turns out that specifying  https://<your_blog_here>.wordpress.com/wp-app.php doesn't actually get you a secure connection... all it does it retrieves a relatively static service document securely. Unfortunately, that document points you to unsecured collections and category documents.

The fix is relatively straightforward, and attached as a patch. But there is a second problem in that users of RSD will never discover the secure connection (unlike xml-rpc, supporting https is a requirement for AtomPub). This is also included in the patch.

Finally, there is a small issue with the RSD in that Atom doesn't have a notion of a "blogID", and the  definition of RSD indicates that blogID should be "" in such circumstances. That, too, is included in the patch.

Original patch did not check for https correctly in the RSD

Not quite sure this patch is right at the moment.

Is doing the callback https check on every request to xmlrpc.php really a good idea? Would we not do better to just make sure if you access via https then you stay on https by basing the returned urls on the request url?

Am I misreading line 20 in xmlrpc.php incorrectly? The intent of this patch is to only do this check when fetching the rsd document.

See  this post for background. Some place in the traversal from http://foo.wordpress.com/ => xmlrpc.php?rsd => /wp-app.php/service => /wp-app.php/posts or /wp-app.php/attachments there needs to be an indication that https should be used. Doing this when rendering the front-page would clearly be overkill. Doing it on every fetch of the service document would be better. Doing it only when fetching the discovery document seems (to me at least) to be better yet.

Replying to rubys:

Am I misreading line 20 in xmlrpc.php incorrectly? The intent of this patch is to only do this check when fetching the rsd document.

See  this post for background. Some place in the traversal from http://foo.wordpress.com/ => xmlrpc.php?rsd => /wp-app.php/service => /wp-app.php/posts or /wp-app.php/attachments there needs to be an indication that https should be used. Doing this when rendering the front-page would clearly be overkill. Doing it on every fetch of the service document would be better. Doing it only when fetching the discovery document seems (to me at least) to be better yet.

Sorry - I read the patch too quick :-( Indeed this does only apply when we are returning the rsd.

I think i would be happier if we moved the check for https availablity out to a generic function and then just had an apply_filter call in xmlrpc.php so that a plugin could force a https url without the run-time cost of the check if the admin knows that https is available for accessing the blog.

Alternative patch which moves the code around a bit

Could you try that new untested patch on for size?

reworked and tested patch

Replying to westi:

Could you try that new untested patch on for size?

A number of minor issues fixed (unmatched parens in xmlrpc.php, get_bloginfo does an implicit echo, apply_filters does not do an implicit echo).

One substantive change: blog_is_accessable_via_ssl() => url_is_accessable_via_ssl($url). Two reasons for this (1) on my test site  https://rubix.home/wordpress (note no trailing slash) returns a 404, and (2) this given the potential plugin the full url and complete freedom to modify any or all of it.

P.S. s/accessable/accessible/ ?

Replying to rubys:

Replying to westi:

Could you try that new untested patch on for size?

A number of minor issues fixed (unmatched parens in xmlrpc.php, get_bloginfo does an implicit echo, apply_filters does not do an implicit echo).

One substantive change: blog_is_accessable_via_ssl() => url_is_accessable_via_ssl($url). Two reasons for this (1) on my test site  https://rubix.home/wordpress (note no trailing slash) returns a 404, and (2) this given the potential plugin the full url and complete freedom to modify any or all of it.

P.S. s/accessable/accessible/ ?

Thanks for the test and update - I had to run and have dinner so I chucked up my in progress code! I'll have a look at getting this checked in tomorrow

(In [6339]) Ensure that we offer https access to atom if it is available. Fixes #5298 props rubys.

Didn't work for non-SSL :-( see [6340] for fix.

Replying to westi:

Didn't work for non-SSL :-( see [6340] for fix.

Good catch! Thanks!