Cannot login and logout on mobile device if desktop template is selected

[riffraff666]

Hello everybody,
I have a website based on Joomla 2.5, and I have installed the mobile basic template.

If I browse the website with a mobile android device, the mobile device is correctly detected so the mobile basic template is automatically chosen.

Under this conditions, if I open the login page and login with user and password, I can login successfully, and then I can logout with the logout button.

However, if I switch to the desktop version of the browser (in which the blue lotus template - thegrue.org - is used) and then I open the login page, I cannot login. If I try it, after few seconds I'm redirected again to the login page. And conversely, if I am already logged in from mobile template and then I switch to the desktop template, I cannot logout if I click the logout button.

I have debugged it remotely from a PC (with a USB debug session) with Chrome browser and I got the following events in the network panel (I have just altered the website name to "example.com")

Code: Select all

curl 'https://www.example.com/login.html' -H 'cookie: __cfduid=d4d2a2e17b5f9cb1d81c743bea135d71f1520545564; 5f0149c105d4b9d657924dfade925b47=f9c355a3e0f97fd11ea5bb26f445dd36; mjmarkup=desktop; _ga=GA1.2.1395993738.1520545571; _gid=GA1.2.588834092.1520545571' -H 'origin: https://www.example.com' -H 'accept-encoding: gzip, deflate, br' -H 'accept-language: en-US,en;q=0.9,it-IT;q=0.8,it;q=0.7,es-MX;q=0.6,es;q=0.5' -H 'upgrade-insecure-requests: 1' -H 'user-agent: Mozilla/5.0 (Linux; Android 5.1; G20 Build/LMY47I) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.137 Mobile Safari/537.36' -H 'content-type: application/x-www-form-urlencoded' -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8' -H 'cache-control: max-age=0' -H 'authority: www.example.com' -H 'referer: https://www.example.com/login?device=desktop' --data 'username=johnsmith&password=123456&remember=yes&Submit=Log+in&option=com_users&task=user.login&return=aW5kZXgucGhwP0l0ZW1pZD00NzM%3D&78501b9a5204ed2903096ef39cb343a6=1' --compressed ;

curl 'https://www.example.com/login.html?device=' -H 'cookie: __cfduid=d4d2a2e17b5f9cb1d81c743bea135d71f1520545564; 5f0149c105d4b9d657924dfade925b47=f9c355a3e0f97fd11ea5bb26f445dd36; mjmarkup=desktop; _ga=GA1.2.1395993738.1520545571; _gid=GA1.2.588834092.1520545571' -H 'accept-encoding: gzip, deflate, br' -H 'accept-language: en-US,en;q=0.9,it-IT;q=0.8,it;q=0.7,es-MX;q=0.6,es;q=0.5' -H 'upgrade-insecure-requests: 1' -H 'user-agent: Mozilla/5.0 (Linux; Android 5.1; G20 Build/LMY47I) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.137 Mobile Safari/537.36' -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8' -H 'cache-control: max-age=0' -H 'authority: www.example.com' -H 'referer: https://www.example.com/login?device=desktop' --compressed ;

curl 'https://www.example.com/login.html?device=desktop' -H 'cookie: __cfduid=d4d2a2e17b5f9cb1d81c743bea135d71f1520545564; 5f0149c105d4b9d657924dfade925b47=f9c355a3e0f97fd11ea5bb26f445dd36; mjmarkup=desktop; _ga=GA1.2.1395993738.1520545571; _gid=GA1.2.588834092.1520545571' -H 'accept-encoding: gzip, deflate, br' -H 'accept-language: en-US,en;q=0.9,it-IT;q=0.8,it;q=0.7,es-MX;q=0.6,es;q=0.5' -H 'upgrade-insecure-requests: 1' -H 'user-agent: Mozilla/5.0 (Linux; Android 5.1; G20 Build/LMY47I) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.137 Mobile Safari/537.36' -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8' -H 'cache-control: max-age=0' -H 'authority: www.example.com' -H 'referer: https://www.example.com/login?device=desktop' --compressed ;
(...)

Then I have done exactly the same test in another website of mine, which is an exact copy of the first website, and for some strange reason the issue doesn't happen. Here are the first network events:

Code: Select all

curl "https://www.example.com/login.html" -H "cookie: __cfduid=d745e79ada496996a2ebd14386ea3f50e1512200042; _ga=GA1.2.879855785.1512200047; _gid=GA1.2.162231340.1520406020; 795a0b657f5210881eccf88c66c0a7dd=en-GB; 5f0149c105d4b9d657924dfade925b47=351865effcb616039e285ec3fd5ba0fc" -H "origin: https://www.example.com" -H "accept-encoding: gzip, deflate, br" -H "accept-language: it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7" -H "upgrade-insecure-requests: 1" -H "user-agent: Mozilla/5.0 (Linux; Android 7.1.2; A101 Build/N2G47O) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.137 Mobile Safari/537.36" -H "content-type: application/x-www-form-urlencoded" -H "accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8" -H "cache-control: max-age=0" -H "authority: www.example.com" -H "referer: https://www.example.com/login.html?device=desktop" --data "username=johnsmith^&password=123456^&remember=yes^&Submit=Log+in^&option=com_users^&task=user.login^&return=aW5kZXgucGhwP0l0ZW1pZD00NzM^%^3D^&a9145ed3e5ab37749e395ccd478078f1=1" --compressed &

curl "https://www.example.com/orders.html" -H "cookie: __cfduid=d745e79ada496996a2ebd14386ea3f50e1512200042; _ga=GA1.2.879855785.1512200047; _gid=GA1.2.162231340.1520406020; 795a0b657f5210881eccf88c66c0a7dd=en-GB; 5f0149c105d4b9d657924dfade925b47=351865effcb616039e285ec3fd5ba0fc; f7b1195650b55cc425fe8e2d69568220=4C124510+6435D+45A+7145913755F525240445A505B59105C4D514A4C134F1A47514310145E41+115581422705552+0+7+3+0174C" -H "accept-encoding: gzip, deflate, br" -H "accept-language: it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7" -H "upgrade-insecure-requests: 1" -H "user-agent: Mozilla/5.0 (Linux; Android 7.1.2; A101 Build/N2G47O) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.137 Mobile Safari/537.36" -H "accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8" -H "cache-control: max-age=0" -H "authority: www.example.com" -H "referer: https://www.example.com/login.html?device=desktop" --compressed &
(...)

After the first event, the second one is already happening in the registered area, so the login has already been successfully done.

So the trick is inside the first request. Comparing them, I could see that in the bad case the cookie mjmarkup=desktop is present, while in the good case it is not present.
In fact, in the bad case, after the first request there are other repeated requests with the same url, with the addition of the suffix "?device=" and then "?device=desktop".

Also in the logout, the difference between the good and bad case is the "mjmarkup=desktop". Here is the first network event in the bad case:

Code: Select all

curl "https://www.example.com/it/" -H "cookie: __cfduid=dff022a4aebdca243f17c65e08df1b0981512199974; _ga=GA1.2.1048130598.1512199981; _gid=GA1.2.740733611.1520184847; 5f0149c105d4b9d657924dfade925b47=780e7515312e1adf547bf4b75595baa3; f7b1195650b55cc425fe8e2d69568220=4C124510+6435D+45A+7145913755F525240445A505B59105C4D514A4C134F1A47514310145E41+115581422705552+0+7+3+0174C; _gat=1; 795a0b657f5210881eccf88c66c0a7dd=it-IT; mjmarkup=desktop" -H "origin: https://www.example.com" -H "accept-encoding: gzip, deflate, br" -H "accept-language: it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7" -H "upgrade-insecure-requests: 1" -H "user-agent: Mozilla/5.0 (Linux; Android 7.1.2; A101 Build/N2G47O) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.137 Mobile Safari/537.36" -H "content-type: application/x-www-form-urlencoded" -H "accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8" -H "cache-control: max-age=0" -H "authority: www.example.com" -H "referer: https://www.example.com/it/?device=desktop" --data "Submit=Esci^&option=com_users^&task=user.logout^&return=aW5kZXgucGhwP0l0ZW1pZD01NTU^%^3D^&1eed3cd1d1e47d03971bab59bcec31ea=1" --compressed &

Here is the first network event in the good logout case:

Code: Select all

curl "https://www.example.com/it/" -H "cookie: __cfduid=d745e79ada496996a2ebd14386ea3f50e1512200042; _ga=GA1.2.879855785.1512200047; _gid=GA1.2.162231340.1520406020; 5f0149c105d4b9d657924dfade925b47=6c868c44f46991d44e904c318569ff40; f7b1195650b55cc425fe8e2d69568220=4C124510+6435D+45A+7145913755F525240445A505B59105C4D514A4C134F1A47514310145E41+115581422705552+0+7+3+0174C; 795a0b657f5210881eccf88c66c0a7dd=it-IT; _gat=1" -H "origin: https://www.example.com" -H "accept-encoding: gzip, deflate, br" -H "accept-language: it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7" -H "upgrade-insecure-requests: 1" -H "user-agent: Mozilla/5.0 (Linux; Android 7.1.2; A101 Build/N2G47O) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.137 Mobile Safari/537.36" -H "content-type: application/x-www-form-urlencoded" -H "accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8" -H "cache-control: max-age=0" -H "authority: www.example.com" -H "referer: https://www.example.com/it/?device=desktop" --data "Submit=Esci^&option=com_users^&task=user.logout^&return=aW5kZXgucGhwP0l0ZW1pZD01NTU^%^3D^&cc9ac9d20fac99f044fd7a4b76da6f7c=1" --compressed &

So in summary, the problem is in some way related to the "mjmarkup=desktop" cookie, which is used by the mobile joomla component to switch from the default mobile template to the desktop template. This causes the server to ask the client to send a new request with the suffix "?device=desktop", and for some strange reason this screws up the login process.

How can I avoid this?
Best regards
Alberto

[riffraff666]

I have an update. I have taken some trace logs inside the function public function dispatch($component = null) in /public_html/includes/application.php. In particular, I have traced the contents of _POST[]

Code: Select all

$input = JFactory::getApplication()->input;
$post_array = $input->getArray($_POST);

- When the logout is successful, the _POST contains the right things:

Code: Select all

array(5) {
  ["Submit"]=>
  string(7) "Log out"
  ["option"]=>
  string(9) "com_users"
  ["task"]=>
  string(11) "user.logout"
  ["return"]=>
...

Furthermore, the component that is retrieved by the dispatch() function is correct and it is com_users

Code: Select all

$component = JRequest::getCmd('option');

- When the logout fails (on the android device), the _POST doesn't contain any data.

Code: Select all

array(0) {
}

Furthermore, the component is not com_users, but another one.

Another trace that I have taken is in the index.php of the website.
If I take the trace of the _POST (in the same way I take it inside the dispatch) before the $app->initialise(), the _POST still contain valid data.
If I take the trace of the post after the $app->initialise()
- In the successful logout case I still have valid data
- In the unsuccessful logout case the _POST is empty.

So it looks like that a wrong application is called.
Does anybody have a clue to solve this puzzle?