{"id":8760,"date":"2018-01-03T04:00:40","date_gmt":"2018-01-03T08:00:40","guid":{"rendered":"https:\/\/blog.litespeedtech.com\/?p=8760"},"modified":"2018-01-03T04:00:40","modified_gmt":"2018-01-03T08:00:40","slug":"wpw-password-protected-posts","status":"publish","type":"post","link":"https:\/\/lswp.store\/index.php\/2018\/01\/03\/wpw-password-protected-posts\/","title":{"rendered":"WpW: Password Protection and Caching"},"content":{"rendered":"

\"WordPress<\/p>\n

Happy New Year, and welcome to another installment of WordPress Wednesday<\/a>!<\/p>\n

Disclaimer<\/strong>: The information contained in this post is accurate for LSCWP v1.6.6.1 [release log<\/a>]. If you are using a newer version of the plugin, some details may have changed. Please refer to our wiki<\/a> for the latest!<\/em><\/p>\n

Let\u2019s talk about the relationship between password protection and caching. If you have ever had reason to hide one of your posts from the public view, you may have chosen to protect it with a password. Password-protected posts are a useful way to ensure that your content is visible only to a specific audience. WordPress cache plugins that use rewrite rules to define their caching behavior can handle password-protected posts, but are you aware that they may also be having an impact on other areas of your site that are not<\/em> hidden behind a password?<\/p>\n

Today we\u2019re going to explore password-protected posts<\/strong>: How do you make one? How are they cached? How do special rules for password protection affect the rest of your site? And how does LiteSpeed Cache do it differently?<\/p>\n

What is a password-protected post?<\/h2>\n

Just like it sounds, a password-protected post is a blog post that a visitor cannot access without a password. When a visitor (let\u2019s call him Fred) accesses http:\/\/www.example.com\/password-protected-post<\/code> for the first time, he is shown a prompt. Fred must enter the correct password before he is shown the post\u2019s content.<\/p>\n

The password is hashed and stored as a cookie in Fred\u2019s browser, which means he only has to enter the password correctly once. From that point, and for the life of the cookie, any time Fred visits http:\/\/www.example.com\/password-protected-post<\/code>, he will be taken directly to the post content, and not be prompted for the password.<\/p>\n

It\u2019s worth noting, by the way, that Fred could also enter an incorrect<\/em> password, and it would be hashed and stored as a cookie in his browser. The contents of the post would, of course, not be shown to him in that case, but the cookie would still be saved in his browser.<\/p>\n

How do you password-protect a post?<\/h2>\n

\"WordPress<\/a><\/p>\n

To create a password-protected post, first create a post, or edit an existing one. In the Edit Post<\/strong> screen, click Edit<\/code> next to Visibility: Public<\/strong>. Select Password Protected<\/code> and enter the password you wish to use. Here we\u2019ve chosen supersecretpassword<\/code> but you may want to be more clever than that \ud83d\ude09<\/p>\n

Press OK<\/code> to save your choice. Make any additional edits that you wish to the post, and press Publish<\/code> (or Update<\/code> if you\u2019re editing a post that has previously been published.)<\/p>\n

Password Protection and Caching<\/h2>\n

What happens when a password-protected post is cached?<\/p>\n

First, it\u2019s important to point out that we\u2019re talking about the kind of caching that is accomplished through rewrite rules. We talk more about this in our LSCaching 101 post<\/a>, if you want to know more, but essentially, the most effective WordPress caching plugins use rewrite rules to manage the cache. <\/strong><\/p>\n

LiteSpeed Cache for WordPress is no exception. We, too, use rewrite rules, but they are not the only tools in our cache toolbox.<\/p>\n

\"WordPress<\/p>\n

If you remember our example with Fred, you\u2019ll notice that password-protected posts require special handling because the posts exist in two forms: the form that is just a prompt for the user to enter the password, and the form that is the full content of the post. We want the latter to show only if the user has entered the correct password, otherwise we will display the former.<\/p>\n

When you have a rewrite-rule-based cache, generally the version with the password prompt is cached, and the full content version is NOT, and which one gets displayed depends on the existence of the password cookie.<\/p>\n

Most cache plugins will use a rewrite rule to detect the password cookie. If it exists (meaning the user has entered a password) then the page is not served from cache. So far so good; this is exactly what we want to happen. Remember the cached version of the page is the one that only displays the password prompt. Once the valid password is entered, we want the uncached version so that the full content is shown.<\/p>\n

Where does this go wrong?<\/h2>\n

Rewrite rules for caching purposes do not single out individual WordPress posts. This means that when you are using a rewrite rule to determine if the password cookie exists, that rewrite rule applies to all of the pages on the site.<\/p>\n

Let that sink in for a minute.<\/p>\n

Put another way: Using rewrite rules, if one page is password-protected and the cookie is detected, the entire site will be treated like that password-protected page<\/em> (i.e. not cached) for that viewer for the entire life of the cookie<\/em>. Ouch.<\/p>\n

For example: Fred visits your one password-protected post, and enters a password (maybe even an incorrect one). The cookie is stored in his browser, the rewrite rule detects the cookie, and serves the uncached contents of the password-protected post to him. After that, Fred moves on to explore the other parts of your site, but he still has that password cookie stored, and the rewrite rule detects it no matter what pages he visits. As such, none of the pages of your site will ever be served to Fred from the cache until he manually clears that cookie from his browser.<\/p>\n

This is clearly not ideal.<\/p>\n

How is LiteSpeed better?<\/h2>\n

LiteSpeed avoids this problem altogether. If you recall, LiteSpeed Cache for WordPress has a special relationship with your LiteSpeed Web Server. Because of this relationship, we can use HTML request headers to look for the password cookie, and we can do it on an as-needed basis<\/em>. This means, LSCWP is not bound by rewrite rules like other plugins.<\/p>\n

If the password cookie exists, we only care about it in reference to the password-protected pages. Instead of relying on rewrite rules to detect the password cookie, LSCache relies on response headers to let it know when it is appropriate to even look<\/em> for a password cookie. If the plugin doesn\u2019t request a password cookie for that particular post, then LSCache doesn\u2019t bother to detect one. Because of this, all of the non-password-protected posts in the site can be served to that visitor from the cache, as they should be.<\/p>\n

In conclusion<\/h2>\n

You can see how setting a password on a post can have surprising and unintended consequences for the rest of your site! If you\u2019re using a plugin that relies entirely on rewrite rules to define its caching behavior, then your only recourse is to instruct your visitors to erase their cookies once in a while.<\/p>\n

Or, you can switch to LiteSpeed Cache<\/a>. (Come on over to our side! We\u2019d love to have you!)<\/p>\n

—<\/p>\n

Have some of your own ideas for future WordPress Wednesday<\/a> topics? Leave us a comment!<\/p>\n

Don\u2019t forget to meet us back here next week for the next installment. In the meantime, here are a few other things you can do:<\/p>\n