@fevangelou On reading your comment for testing it it enoth to test that rememberme in Frontend still works? Thanks

Does this invalidate existing remember me cookies?

Does this invalidate existing remember me cookies?

The existing cookies will not be invalidated per se and will stay on the computer until they time out and the browser deletes them eventually. They're just no longer used with this PR.

In the end, the result is the same, it will force everyone to log in again after that update.

Technically it's a B/C break, not a big one but certainly one users will notice.

Since the cookie name changes, yes, it will not be B/C as a new cookie will be introduced to the user's browser. Of course, since the existing cookie name is based off the UA string, it's possible that even a browser update invalidates existing "remember me" cookies. In any case, I believe the pros outweigh the cons here as (like I said) this simple/little fix significantly improves compatibility between Joomla and Varnish (and other similar caching proxies).

Two things:

1) PR is out of sync, merge staging in please to address conflicts.
2) Can we add a B/C layer that checks for the existing cookie name and if so updates the user to the new one? I think that's a fair compromise to that concern.

Personally I've got no issue with this, but if we can stop "breaking b/c out of habit on every release" then we're making progress.

Yes, let's add one more option in Joomla that will not be necessary after a cookie expires... That's how broken Joomla will be. Not to mention this new option won't make any sense after it's enabled for the first time.

Michael didn't mention an option. You can be quite sure that he would never suggest that
He meant an automatic detection and conversion of existing cookies if present. Which makes sense to me.

This is so funny...

Whadda ya know? Backwards compatibility WILL break once more in Joomla 3.5 as published OFFICIALLY here: https://developer.joomla.org/news/627-joomla-3-5-what-s-in-store-for-us.html

"Backwards Compatibility break

We have a backwards compatibility promise to make sure code doesn’t suddenly break. However there are circumstances that can force us to no longer keep this promise. In Joomla 3.5 this is the case. Due to changes in PHP 7, we had to rename the String class to StringHelper otherwise Joomla! cannot run on PHP 7. This is a very minor change and we don’t expect any issues from it. For those interested, you can read more about it at Update to String package 1.3."

Yet, you're still deciding and deciding and deciding whether the damn "remember me" cookie should be renamed or not and if 10 more params should be added to control that behaviour.

Why make people's life easier, right?

I guess you think it's cooler if Varnish (the no.1 caching proxy on the web for any serious high performance site deployment) is 100% incompatible with Joomla unless core CMS code is hacked.

That was a required change to support PHP7 and presented no alternative.
Your proposal can be done in a B/C way. So, in my ""piss off, we know
better" Joomla-clique attitude", this is my saying adjust your pull request
or close the damn thing.

On Thursday, October 29, 2015, Fotis Evangelou notifications@github.com
wrote:

This is so funny...

Whadda ya know? Backwards compatibility WILL break once more in Joomla
3.5 as published OFFICIALLY here:
https://developer.joomla.org/news/627-joomla-3-5-what-s-in-store-for-us.html

"Backwards Compatibility break

We have a backwards compatibility promise to make sure code doesn’t
suddenly break. However there are circumstances that can force us to no
longer keep this promise. In Joomla 3.5 this is the case. Due to changes in
PHP 7, we had to rename the String class to StringHelper otherwise Joomla!
cannot run on PHP 7. This is a very minor change and we don’t expect any
issues from it. For those interested, you can read more about it at Update
to String package 1.3."

Yet, you're still deciding and deciding and deciding whether the damn
"remember me" cookie should be renamed or not and if 10 more params should
be added to control that behaviour.

Why make people's life easier, right?

I guess you think it's cooler if Varnish (the no.1 caching proxy on the
web for any serious high performance site deployment) is 100% incompatible
with Joomla unless core CMS code is hacked.

—
Reply to this email directly or view it on GitHub
#7677 (comment).

Please be kind and write a lengthy article/essay as to why PHP7 support would break. Explain in detail and spare no words. Then "Travis CI"-the-crap-out-of-it so we know it meets the Joomla standards. If the build passes the checks, then and only then we'll consider your argument truthful.

Check CI builds for the 3.4 release tags and note the failures on the PHP 7
build. Then refer to the changes from
#6600 and the associated
commentary to understand why the B/C breaking change was necessary for.

On Thursday, October 29, 2015, Fotis Evangelou notifications@github.com
wrote:

Please be kind and write a lengthy article/essay as to why PHP7 support
would break. Explain in detail and spare no words. Then "Travis
CI"-the-crap-out-of-it so we know it meets the Joomla standards. If the
build passes the checks, then and only then we'll consider your argument
truthful.

—
Reply to this email directly or view it on GitHub
#7677 (comment).

There is a reason for the hashed useragent and not simply using a cookie named "REMEMBER_ME_COOKIE" and that was obfuscating the cookie that is responsible for this task. For the same reason we have a random name for the session cookie and don't call it SESSION. Of course we can now argue if obfuscation works at all, but in this case I would be on the side of caution. If you prefix it with JRememberme_, we might as well drop the hash after that (I know, I know, that would let it fail on different installations on the same host, but I'm talking security wise.)

I never mentioned dropping the hash. But having no prefix to identify it's Joomla limits the use of the CMS behind any reverse caching proxy by default. Even if there is a solid plugin to patch this behaviour, someone has to install it.

As an example, cause this is not related to Varnish only, a software I recently released called Engintron (engintron.com) installs Nginx as a reverse caching proxy in front of Apache on cPanel servers. As you can understand, it's geared for installation by hosting companies or agencies. On an upcoming update of Engintron I will add specific exclusions for WordPress and other CMSs so you can use full page caching besides the default (current) 1 sec micro caching option. The latter works just fine with Joomla but the benefits of having longer caching are limited by the fact that Joomla's cookies don't use a prefix or other unique identifier. On top of that, Joomla uses sessions for guest users which further complicates caching. In fact, by default Nginx or Varnish (as proxies) will never cache any Joomla generated page, because it contains a cookie that is different per user. Thus each served page is considered different per each user. And although these proxies can ignore or strip cookies from each request, the fact that the session cookie is used for logins kills any way to identify when a guest is turned to a logged in user. For Varnish specifically it's common to strip all Joomla cookies and leave only certain pages that are used as entry points for users to login so Joomla's session mechanism and login works. A great example is joomlaworks.net. Via a terminal run "curl -I URL_HERE" and examine the headers for that site's homepage and then the /members page to see what I mean.

So all in all, it's not just the remember me function. Joomla should have a prefix on all its cookies. Unfortunately, as although we have extensive experience as a company having deployed some of the highest traffic Joomla sites worldwide, Joomla just ignores us to the benefit of other CMS. :(

As a side note let me add that we've built the mechanism to have Joomla be "reverse caching proxy" friendly into K2 - a user plugin to set a cookie for logged in users when they log in (unset it when they log out) plus a simple HTTP header via K2's system plugin to also identify a user is logged in which works for both guests and users. No sensitive data are exposed in public and it just works.

If you accept this pull request I'd be more than happy to contribute the rest of the code used in K2 for Joomla's benefit. Times are changing and having just Apache serve a site doesn't always fit the bill. This boils down both to performance as well as costs involved to operate a site. Using Varnish and/or Nginx instead of Apache or in front of Apache allows for smaller hosting bills in the end. It's that simple.

I understand where you come from, don't get me wrong. I also don't think that a targeted attack is prevented by this random session name. But I do think that this makes mass-hackings a tad bit more cumbersome for the hackers. Maybe we could have a config option for this? Doesn't have to be visible or something... Idk. I just don't want to drop a "feature" like this so easily.

In any case, please fix the conflicts that are currently present.

Well, there are more than one ways to identify a site is using Joomla: from
the request headers (fastest) to URLs for e extensions with known exploits.
I doubt the cookie name change would have any impact if you consider most
of these tools that are used to scan sites are usually bots with no JS
capabilities.

Which conflicts are you referring to by the way? I think it passed the CI's
tests already (code formatting issues)...
On Feb 23, 2016 9:28 PM, "Hannes Papenberg" notifications@github.com
wrote:

I understand where you come from, don't get me wrong. I also don't think
that a targeted attack is prevented by this random session name. But I do
think that this makes mass-hackings a tad bit more cumbersome for the
hackers. Maybe we could have a config option for this? Doesn't have to be
visible or something... Idk. I just don't want to drop a "feature" like
this so easily.

In any case, please fix the conflicts that are currently present. [image:
]

—
Reply to this email directly or view it on GitHub
#7677 (comment).

Github says that this branch has conflicts, so it can not be merged automatically right now.

I will update my commits to include the additional cookie for logged in users as well as the HTTP headers to signify a user's logged in status, so as a solution it's fully complete to address how Joomla works behind reverse caching proxies. Once I'm ready I'll create a new pull request and I'll leave it up to you to decide what you want merged in. Hannes, thanks again.

@fevangelou have you been able to find the time to update the PR as you stated above?

If you don't mind, please keep the issue open until Monday so I have some
extra time to commit the changes.
On May 5, 2016 10:35 PM, "Brian Teeman" notifications@github.com wrote:

@fevangelou https://github.com/fevangelou have you been able to find

the time to update the PR as you stated above?

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/7677
https://issues.joomla.org/tracker/joomla-cms/7677.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#7677 (comment)

@brianteeman As also promised to @Hackwar I have additional file changes contributed so I had to make a new PR here: #10373

Closing this one.