WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#5298 closed defect (bug) (fixed)

https atom service document doesn't point to https collections

Reported by: rubys Owned by: westi
Milestone: 2.5 Priority: normal
Severity: normal Version: 2.3.1
Component: General Keywords: has-patch
Focuses: Cc:

Description

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.

Attachments (3)

https-app.patch (4.3 KB) - added by rubys 7 years ago.
Original patch did not check for https correctly in the RSD
5298.diff (5.4 KB) - added by westi 7 years ago.
Alternative patch which moves the code around a bit
5298.patch (5.4 KB) - added by rubys 7 years ago.
reworked and tested patch

Download all attachments as: .zip

Change History (15)

comment:1 @josephscott7 years ago

  • Cc josephscott added

comment:2 @foolswisdom7 years ago

  • Keywords has-patch added
  • Milestone changed from 2.5 to 2.4
  • Version set to 2.3.1

@rubys7 years ago

Original patch did not check for https correctly in the RSD

comment:3 @westi7 years ago

  • Owner changed from anonymous to westi
  • Status changed from new to assigned

comment:4 @westi7 years ago

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?

comment:5 follow-up: @rubys7 years ago

  • Cc rubys added

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.

comment:6 in reply to: ↑ 5 @westi7 years ago

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.

@westi7 years ago

Alternative patch which moves the code around a bit

comment:7 follow-up: @westi7 years ago

Could you try that new untested patch on for size?

@rubys7 years ago

reworked and tested patch

comment:8 in reply to: ↑ 7 ; follow-up: @rubys7 years ago

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/ ?

comment:9 in reply to: ↑ 8 @westi7 years ago

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

comment:10 @westi7 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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

comment:11 follow-up: @westi7 years ago

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

comment:12 in reply to: ↑ 11 @rubys7 years ago

Replying to westi:

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

Good catch! Thanks!

Note: See TracTickets for help on using tickets.