WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 years ago

#27565 closed defect (bug) (fixed)

Recent Posts Widget should include scheme in cache key

Reported by: dllh Owned by: wonderboymusic
Milestone: 4.4 Priority: normal
Severity: normal Version: 2.8
Component: Widgets Keywords: needs-patch
Focuses: Cc:

Description

Repro:

  1. Run WP on a site with SSL enabled but optional and with an object cache.
  2. Enable the Recent Posts widget.
  3. Create some posts.
  4. Visit the site from the non-SSL url.
  5. Now visit the site from the SSL url.

Expected: Items linked in the recent posts widget will use the same scheme as the site itself.

Actual: Whatever was last cached is what's used. The result is that if you visited the site via https but someone else cached data from http, you'll get insecure links when your expectation is that you'll continue to browse the site via ssl.

This can be fixed by using the scheme in the cache key so that we're always serving the right links when served from the object cache.

Attachments (4)

default-widgets.patch (755 bytes) - added by dllh 5 years ago.
27565.diff (1.0 KB) - added by westi 5 years ago.
Updated patch to also purge both cache variants.
27565.2.diff (1.1 KB) - added by obenland 4 years ago.
27565.3.diff (2.3 KB) - added by wonderboymusic 4 years ago.

Download all attachments as: .zip

Change History (16)

#1 follow-ups: @johnbillion
5 years ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to Future Release
  • Version set to 2.8

Even better would be to use home_url() in the cache key, but this makes it likely to become longer than the allowed key size of 64 chars.

#2 in reply to: ↑ 1 @dllh
5 years ago

Replying to johnbillion:

Even better would be to use home_url() in the cache key, but this makes it likely to become longer than the allowed key size of 64 chars.

I guess you could hash the home_url() or something. That makes it a little less obvious what you're looking at if you happen to be peeking at cache keys, but it's also more resilient to hostname changes.

#3 in reply to: ↑ 1 @westi
5 years ago

Replying to johnbillion:

Even better would be to use home_url() in the cache key, but this makes it likely to become longer than the allowed key size of 64 chars.

I think using home_url is probably a little excessive, if we are really worried about cache pollution when home_url changes we can just hook the purging function onto that too.

@westi
5 years ago

Updated patch to also purge both cache variants.

#4 @obenland
4 years ago

  • Owner set to obenland
  • Status changed from new to accepted

#5 @obenland
4 years ago

  • Milestone changed from Future Release to 4.4

@obenland
4 years ago

#6 follow-up: @obenland
4 years ago

  • Keywords commit added

Refreshed westi's patch. Can anyone see anything wrong with it?

#7 in reply to: ↑ 6 @westonruter
4 years ago

  • Keywords commit removed

Replying to obenland:

Refreshed westi's patch. Can anyone see anything wrong with it?

What about the situation where the site can be accessed via multiple domains? For instance, if setting the WP_HOME constant to include $_SERVER['HTTP_HOST'], then the cached values could be wrong.

So what if instead of using is_ssl() ? 'https' : 'http' in the cache key, it instead uses home_url()?

This would necessarily change how the cache deletion is done, since it wouldn't be known all of the possible home URLs that could appear. So the cached value could instead be an array of cached outputs mapped to the home_url that was active for that given cache. In that way, you can still just delete one cache value and it will purge the caches for all variations of the home URL.

This ticket was mentioned in Slack in #core by obenland. View the logs.


4 years ago

#9 @johnbillion
4 years ago

  • Keywords needs-patch added; has-patch removed

#10 @wonderboymusic
4 years ago

  • Owner changed from obenland to wonderboymusic
  • Status changed from accepted to assigned

why on earth are we caching the HTML output? The only other place this is done is the 2011 Ephemera widget

#11 @wonderboymusic
4 years ago

27565.3.diff ditches the cache completely. No other widgets, except for Recent Comments, cache like this. This was 7 releases before $split_the_query. Without an object cache, these queries already happen. With an object cache, posts are served from the cache. This will remove any cached scheme weirdness automatically.

#12 @wonderboymusic
4 years ago

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

In 34464:

Recent Posts Widget: remove HTML fragment caching. The cache currently doesn't work cross-scheme and causes mixed content issues for links. The widget was written pre-$split_the_query, after which post objects can be served from the cache.

Fixes #27565.

Note: See TracTickets for help on using tickets.