[wp-trac] [WordPress Trac] #15928: wp_get_attachment_url does not check for HTTPS

WordPress Trac noreply at wordpress.org
Sun Nov 23 20:06:32 UTC 2014


#15928: wp_get_attachment_url does not check for HTTPS
--------------------------+-----------------------------
 Reporter:  atetlaw       |       Owner:  boonebgorges
     Type:  defect (bug)  |      Status:  accepted
 Priority:  normal        |   Milestone:  Future Release
Component:  Permalinks    |     Version:  3.0.3
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+-----------------------------

Comment (by boonebgorges):

 joemcgill - Thanks for the additional patches. I think we're starting to
 zero in on the real issue here - which is that the URL we generate for the
 asset must necessarily respect the address at which the asset is actually
 available. But it's not feasible for us to be making external requests
 inside of a function that could be called dozens of time on a single page.

 Now, in a broad sense, I think there might be value in storing in some
 global state whether a given domain is accessible over SSL, and then using
 that information in functions like `wp_get_attachment_url()` to assemble
 URLs. But doing it even *once per page* seems like an unacceptable drag on
 server resources, so I'd argue that this data should be at least semi-
 persistent. And in any case, if we were going to go down this path, it
 should be something that happens outside of the scope of this particular
 function, and is implemented wherever we build asset URLs (like, say,
 `wp_enqueue_script()`). I think this is beyond the scope of what's
 necessary for this ticket.

 As for `wp_get_attachment_url()`: we want to be as aggressive about
 setting HTTPS as possible *without the possibility of false positives*.
 Here's some logic that I think is an improvement on what we currently have
 in place, but is still very conservative:

 {{{
 // If we're on an SSL page, see whether we can force the URL to SSL too.
 if ( is_ssl() && 'https' !== substr( $url, 0, 5 ) ) {
     $baseurl_parts = parse_url( $uploads['baseurl'] );
     if ( parse_url( $url, PHP_URL_HOST ) === $baseurl_parts['host'] &&
 'https' === $baseurl_parts['scheme'] ) {
         set_url_scheme( $url, 'https' );
     }
 }
 }}}

 (I have not tested this code, so it may need fixing, but you get the idea
 :) ) In other words: if the current page is SSL (but the URL being
 generated is not), AND if the current page's domain matches the domain of
 the generated URL, then force HTTPS for the URL. Let's look at how this
 will pan out in a couple different scenarios:

 1. SSL-optional front-end, site_url is non-SSL. Attachment URLs will be
 HTTPS when `is_ssl()`, HTTP when not. This fixes the original bug reported
 in this ticket.
 2. Admin at https://secure.example.com, site_url is http://example.com.
 Attachment URLs will be HTTP. This maintains the status quo of mixed-
 content warnings in the admin, but I argue that it's outside the scope of
 this ticket to fix that problem. (In the long term, we might consider a
 pro-security solution that pre-determines that a URL is not https and
 decides to show alternative markup in those cases. Maybe.)

 What do you think?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/15928#comment:89>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list