#5298 closed defect (bug) (fixed)
https atom service document doesn't point to https collections
Reported by: |
|
Owned by: |
|
---|---|---|---|
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)
Change History (15)
#4
@
17 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?
#5
follow-up:
↓ 6
@
17 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.
#6
in reply to:
↑ 5
@
17 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 thersd
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 thathttps
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.
#8
in reply to:
↑ 7
;
follow-up:
↓ 9
@
17 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/ ?
#9
in reply to:
↑ 8
@
17 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
Original patch did not check for https correctly in the RSD