This is an update for pull request #7677

Description

Reverse caching proxies like Varnish, Nginx etc. (also known as web accelerators) are built to cache the entire page output of a website and thus speed up delivery significantly. Such software works much more efficiently to how page caching is performed internally in Joomla, as PHP & the database (the usual performance bottleneck) are invoked only when the content is required to be constructed and not every time it's served.

The use of such software is not only meant to be used by extremely high performance sites, as even sites with low or moderate traffic can benefit from the speed improvement and thus rank better in search engine results.

Joomla unfortunately cannot work out-of-the-box with reverse caching proxies. This limits Joomla from being easily setup in high performance scenarios without additional custom coding or extensions, unlike other CMSs like WordPress, which already provide the means for reverse caching proxies to operate better with.

There are currently 3 problems that prevent Joomla from working out-of-the-box with reverse caching proxies:

a) sessions for logged in users cannot be easily identified by that software, in other words, a reverse caching proxy is unable to "know" if a user is logged into Joomla and therefore cannot decide whether to serve cached or un-cached output. This obviously has undesired effects where guest users could see sensitive data cached from a previously logged in user.
b) the "remember me" cookie cannot be identified as well (because it's a hashed user agent string) and thus the related functionality is simply broken, even if we fixed (a).
c) Identifying which pages NOT to cache, even when the above conditions are never met. Such a page is the typical user login page and the problem comes from the token used in the login form. Because the token is created from a guest user's session cookie, if the login page (or any page that requires user login - e.g. a user module, a members area etc.) has been previously cached by the reverse caching proxy, then there will be a token mismatch between what gets submitted to the form and the token the actual user would have generated by Joomla if there was no caching implemented at all. That's because reverse caching proxies cache some page from the first visitor that accesses that page. So when a 2nd visitor comes in, the page would essentially display what Joomla generated for the first visitor. And in the case of forms, the 2nd visitor would get the 1st visitor's session token printed on the html of that form. A token mismatch means the visitor could not login without re-submitting the form, which translates to unnecessary user experience issues.

The solution is overall simple and it requires the use of some identifiers in the form of cookies or HTTP headers:

For (a), all we have to do is set an identifier cookie only when users log in. This cookie only acts like a flag telling reverse caching proxies that as long as this cookie is present, the output of the page should never be cached. No sensitive data is exposed and this cookie is destroyed when the user logs out.

For (b), all we have to do is add a prefix to the existing cookie created by Joomla, which is currently a hashed user agent string. This allows reverse caching proxies to check for this prefix and turn off any caching, similar to how it should be done for when users log into a Joomla site.

For (c), the users component (com_users) and the entire Joomla /administrator path should emit an HTTP header which would instruct the reverse caching proxy to NOT cache content at all and therefore allow the Joomla form token to be created from the actual guest attempting to log in. These are the 2 most important user entry points in Joomla. Unfortunately, we cannot count the user login module to this change, because if that module is used on every page of the site, then the HTTP header to prevent caching would emit everywhere and thus beat the point of caching overall. It's a case by design which must be addressed by the developer of each site. As an example, see how we handle user logins at http://www.joomlaworks.net which uses Varnish. You'll notice that every user login leads to a specific page only. This page is excluded from being cached by Varnish and therefore user logins work flawlessly.

The proposed PR currently fixes (a) and (b) which is the most important aspect of Joomla's out-of-the-box interoperability with reverse caching proxies. Issue (c) is less important as it can easily be addressed using an existing boilerplate configuration for Varnish, Nginx etc. When I have a user-configurable solution for this, e.g. a flag in the Joomla menu system to exclude pages from such caching by emitting a special HTTP header, I will make a new PR with required code changes.

To sum things up:

• This is a performance related improvement for Joomla.
• It will allow even smaller sites (in terms of traffic) to benefit from the speed improvement and thus help rank better in search engines.
• It has no impact in existing Joomla sites (aside the fact that the current "remember me" cookie will simply be reset for users on the next update of Joomla - which doesn't really constitute a b/c issue).
• It has no security impact and no sensitive data are exposed. The main prefix "joomla_" used in the cookies added/affected does not pose a security risk as there are many other ways a Joomla site can be identified and even easier (e.g. by loading /robots.txt and checking the excluded paths or /configiration.php and checking the Joomla-distinct message printed - and the list goes on...).
• 3 plugin files are patched to provide a solution for (a) and (b) as described above.

Thank you.

P.S. This is the configuration for Varnish v3.x to detect the "user state" and "remember me" cookies in Joomla properly (it's really typical cookie detection in Varnish):

sub vcl_recv {
    [...other rules...]
    if (req.http.Cookie ~ "joomla_") {
        return (pass);
    }
    [...other rules...]
}

and

sub vcl_fetch {
    [...other rules...]
    if (bereq.http.Cookie ~ "joomla_") {
        return (hit_for_pass);
    }
    [...other rules...]
}

A full example can be found here: https://gist.github.com/fevangelou/84d2ce05896cab5f730a

Summary of Changes

• Added the prefix "joomla_remember_me_" wherever the related cookie name is set in /plugins/authentication/cookie/cookie.php
• Added the prefix "joomla_remember_me_" wherever the related cookie name is set in /plugins/system/remember/remember.php
• Modified /plugins/user/joomla/joomla.php to include the setting/unsetting of the "joomla_user_state" cookie to be used as a flag for when a user logs into Joomla and effectively instruct any reverse caching proxy to NOT cache the site's output.

P.S. The use of "joomla__" (instead of "j__" as naming conventions are usually used in Joomla) was done for clarity. WordPress for example uses "wp_" or "wordpress_" and other CMSs similar more-than-one-letter naming conventions. If we used just "j_*" that might have undesired effects as the cookie name match may be more common.

Testing Instructions

To see the full benefits, use Joomla installed on a LAMP stack with Varnish 3.x and this configuration as a starting point: https://gist.github.com/fevangelou/84d2ce05896cab5f730a

Otherwise just get the update, open up your browser's dev tools and inspect the cookies set when you log in and out and when you tick the "remember me" checkbox in the login forms.

/cc @Hackwar @brianteeman