[wp-trac] [WordPress Trac] #15928: wp_get_attachment_url does not check for HTTPS
WordPress Trac
noreply at wordpress.org
Sun Nov 2 19:50:46 UTC 2014
#15928: wp_get_attachment_url does not check for HTTPS
-------------------------------------+---------------------------
Reporter: atetlaw | Owner: boonebgorges
Type: defect (bug) | Status: accepted
Priority: normal | Milestone: 4.1
Component: Permalinks | Version: 3.0.3
Severity: normal | Resolution:
Keywords: needs-testing has-patch | Focuses:
-------------------------------------+---------------------------
Changes (by boonebgorges):
* keywords: needs-testing 4.1-early needs-patch => needs-testing has-patch
* owner: => boonebgorges
* status: assigned => accepted
* milestone: Future Release => 4.1
Comment:
> Is the general rule to keep tests to one assertion per test?
Yes, please. Even if this sometimes doing extra setup work - it's more
important that the tests be independent of each other than that they run
as efficiently as possible.
> was thinking of the case where you call the wp_get_attachment_url() from
a theme on the front end, which is where I first encountered this bug.
Yeah. Part of what we're seeing here is that there are a number of
different cases, all of which need different handling. The underlying
principle is that images ought to have HTTP URLs when viewing them over
HTTP, and HTTPS when over HTTPS. But, while we can always use `is_ssl()`
to tell whether we are *currently* using SSL (as when using
`wp_get_attachment_url()` directly in a theme file), there are cases in
which we can't be sure whether the eventual consumer of the URL is going
to be using SSL. This is particularly the case when content is generated
in wp-admin but then consumed on the front end, as in the case of
attachment URLs saved in post content.
I will add that, as the original poster suggested, this is a problem in
`wp_upload_dir()`. But that function is used in so many ways that I'm
extremely wary of making any changes there without some extensive review.
All this being said, [attachment:15928.6.patch] makes a couple additional
suggestions. Note that there are really about three different things going
on here, and they could be adopted piecemeal:
* We can simplify the logic in `wp_get_attachment_url()` to simply run
`set_url_scheme( $url )`. It's redundant to check `is_ssl() || (
is_admin() && force_ssl_admin() )` - if you're forcing SSL in the admin,
and you're in the admin, then you're looking at SSL. And using
`set_url_scheme()` without a `$scheme` parameter sets it relative to the
current scheme.
* To solve the specific case of attachment URLs being saved in post
content with the improper scheme, I've made a very narrow modification to
the way our JS generates attachment URLs, so that they use the "network
path" scheme `//`. This should avoid all mixed content warnings in post
content. This change required adding a 'network_path' schema type to
`set_url_scheme()`.
This remains a pretty imperfect solution to some larger underlying
problems regarding the way WP handles the generation of HTTPS URLs, but I
think it addresses most of what's being raised in this ticket. Let's do at
least a subset of it for 4.1. Any thoughts are quite welcome.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/15928#comment:76>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list