@wilsonge - I think this may be related to the issue I mentioned to you yesterday with the online/offline indicator

Having same issue since 3.6.1

On the forum you say this is only for users with ipv6 but you didnt mention that here - was that not correct?

TS (gee2803) mentionned that on the forum.

Can you not confirm that?

No, sorry.

The Who's Online missing sessions issue is affecting both IPV4 and IPV6 cases - users who are returning to site via cookie login (Remember Me)and are as such resuming a session are those whose sessions are not displaying in Who's Online - those users that manually log in after a manual log out ans as such are starting a new session are those whose sessions are being displayed as normal.

das Problem entstand weil man jetzt bei Rückkehr die alte Session löscht und nicht mehr aktualisiert wie bis her
Googel translated
The problem arose because you now in return deletes the old session and no longer updated as until now
plugins/user/joomla/joomla.php -> onUserLogin

We know what change in 3.6.1 made this happen?

My users start to get noticing it

I've tested this on a localhost site J3.6.2 site - I've replaced the plugins/user/joomla/joomla.php file with a J3.6.0 version joomla.php file and the vanishing sessions issue has been rectified - i.e all sessions are shown and significantly sessions resumed via cookie login after global configuration session timeout.
Just done the same on a J3.6.2 live site and results are the same.
Renamed the J3.6.2 joomla.php file first and then added J3.6.0 joomla.php file - haven't much clue as to what I'm doing but seems to have worked ok until at least an official bugfix surfaces.

That's not a good fix as you're reverting a security hardening patch for
3.6.1.

On Friday, August 12, 2016, cuertech notifications@github.com wrote:

I've tested this on a localhost site J3.6.2 site - I've replaced the
plugins/user/joomla/joomla.php file with a J3.6.0 version joomla.php file
and the vanishing sessions issue has been rectified - i.e all sessions are
shown and significantly sessions resumed via cookie login after global
configuration session timeout.
Just done the same on a J3.6.2 live site and results are the same.
Renamed the J3.6.2 joomla.php file first and then added J3.6.0 joomla.php
file - haven't much clue as to what I'm doing but seems to have worked ok

until at least an official bugfix surfaces.

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

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#11556 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoblva4-r9_NZGDOJFEYJ8jlaz7N2ks5qfMH8gaJpZM4Jh_HK
.

@mbabker Agreed but it keeps my non technical and confused social site users off my back in the meantime

Hm I see changes to that file indeed between 3.6.0 and 3.6.2:

    $session = JFactory::getSession();

    // Grab the current session ID
    $oldSessionId = $session->getId();

    // Fork the session
    $session->fork();

    $session->set('user', $instance);


    // Ensure the new session's metadata is written to the database
    $this->app->checkSession();


    // Purge the old session
    $query = $this->db->getQuery(true)




        ->delete('#__session')
        ->where($this->db->quoteName('session_id') . ' = ' . $this->db->quote($oldSessionId));

    try
    {
        $this->db->setQuery($query)->execute();
    }
    catch (RuntimeException $e)
    {

        // The old session is already invalidated, don't let this block logging in
    }<hr /><sub>This comment was created with the <a href="https://github.com/joomla/jissues">J!Tracker Application</a> at <a href="https://issues.joomla.org/tracker/joomla-cms/11556">issues.joomla.org/joomla-cms/11556</a>.</sub>

Correct, as pointed out it was in regards to a security hardening patch. There has already been one report of an extension which stopped working because it was tracking data by storing the session ID in an external source. I can't speak for Kunena or anyone else but anything querying the session database table for things like a count of online users should be unaffected because the changes do nothing but change the session ID, delete the record for the old session ID, and create a record for the new session ID.

Also, anything using a cache would have issues as the cached data is not refreshed on every user authentication action.

Hello, in Kunena to get online users we have a query against #__session table, but the result of this query is cached if i'am remember right.

Having the same problem.

Well I guess we can conclude then it is an Kunena problem and we should continue discussion there? Found this topic of someone refering from there to here

https://www.kunena.org/forum/k4-0-kunena-support/138197-kunena-4-online-users

Hello, in Kunena to get online users we have a query against #__session table, but the result of this query is cached if i'am remember right.

This would be a Kunena behavior then since in core none of the database queries are cached (if you want caching you have to wrap it in JCache API calls). It's possible for the who's online module to be cached (I say that since others have mentioned it here), but beyond that I don't really know anything about Kunena's internals to say more.

Can anyone please confirm this with just core or is this ONLY with kunena

Can anyone please confirm this with just core or is this ONLY with kunena

With core. I have been seeing this problem since joomla 3.6.1.
Module Who's online, Community Builder Online module, Kunena are giving the same results.
Also I had tested on localhost + clean Joomla 3.6.1/3.6.2 - bug still occures.

The who's online module queries directly from the session database table. The ONLY way it could "lose" data is if it's being cached or somehow executing its query in the milliseconds between the user's unauthenticated record being deleted from that table and their authenticated record being inserted.

Also Jomsocial seems to have problems with 3.6.1

Habe es erstmals so gelöst das ich zum Schluss nochmal / wieder eine DB Aktualisierung mache auch wenn ich das nicht für denn besten Wege halte denn eigentlich mussten diese Daten gleich korrekt in die Datenbank gespeichert werden.
übrigens werden die Daten nicht nur von 3 Anbieter wie Kunena abgefragt sondern auch von mindestens ein Joomla Modul (whosonline).

Googel translated
Have solved it for the first time so I finally again / again a DB do update too when I don't think it as best way because actually this data had to be stored right correctly in the database.

by the way the data not only from 3 providers such as Kunena are but queried by at least a Joomla module (whosonline).

 public function onUserLogin($user, $options = array()) {
        $instance = $this->_getUser($user, $options);

        // If _getUser returned an error, then pass it back.
        if ($instance instanceof Exception) {
            return false;
        }

        // If the user is blocked, redirect with an error
        if ($instance->block == 1) {
            $this->app->enqueueMessage(JText::_('JERROR_NOLOGIN_BLOCKED'), 'warning');

            return false;
        }

        // Authorise the user based on the group information
        if (!isset($options['group'])) {
            $options['group'] = 'USERS';
        }

        // Check the user can login.
        $result = $instance->authorise($options['action']);

        if (!$result) {
            $this->app->enqueueMessage(JText::_('JERROR_LOGIN_DENIED'), 'warning');

            return false;
        }

        // Mark the user as logged in
        $instance->guest = 0;

        $session = JFactory::getSession();

        // Grab the current session ID
        $oldSessionId = $session->getId();

        // Fork the session
        $session->fork();

        $session->set('user', $instance);

        // Ensure the new session's metadata is written to the database
        $this->app->checkSession();

        // Purge the old session
        $query = $this->db->getQuery(true)
                ->delete('#__session')
                ->where($this->db->quoteName('session_id') . ' = ' . $this->db->quote($oldSessionId));

        try {
            $this->db->setQuery($query)->execute();
        } catch (RuntimeException $e) {
            // The old session is already invalidated, don't let this block logging in
        }

        // Hit the user last visit field
        $instance->setLastVisit();


        $query = $this->db->getQuery(true)
                ->update($this->db->quoteName('#__session'))
                ->set($this->db->quoteName('guest') . ' = ' . $this->db->quote($instance->guest))
                ->set($this->db->quoteName('username') . ' = ' . $this->db->quote($instance->username))
                ->set($this->db->quoteName('userid') . ' = ' . (int) $instance->id)
                ->where($this->db->quoteName('session_id') . ' = ' . $this->db->quote($session->getId()));


        try {
            $this->db->setQuery($query)->execute();
        } catch (RuntimeException $e) {
            return false;
        }

        // Add "user state" cookie used for reverse caching proxies like Varnish, Nginx etc.
        $conf = JFactory::getConfig();
        $cookie_domain = $conf->get('cookie_domain', '');
        $cookie_path = $conf->get('cookie_path', '/');

        if ($this->app->isSite()) {
            $this->app->input->cookie->set("joomla_user_state", "logged_in", 0, $cookie_path, $cookie_domain, 0);
        }

        return true;
    }

@brianteeman - Core issue. I'm using pretty much the same code in one of my extension and am having the same issue. The only way the online status is updated, is if I log out, then log back in again

do you have caching on for the site?
Do you have caching on for the module?
do you have caching on at a server level

On 19 August 2016 at 12:42, Lodder notifications@github.com wrote:

@brianteeman https://github.com/brianteeman - core issue. I'm using
pretty much the same code in one of my extension and am having the same
issue. The only way the online status is updated, is if I log out, then log
back in again

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11556 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8WBKaOdWWOKOcbHmUV7XdgTtYxpKks5qhZaagaJpZM4Jh_HK
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Nope, no caching what so ever on the site or server side. Also cleared browser caching

can you send me the extension to check out for myself?

On 19 August 2016 at 12:50, Lodder notifications@github.com wrote:

Nope, no caching what so ever. Also cleared browser caching

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11556 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8RA6E3-q0dQY5Fpi5YMEqaqrgfRcks5qhZiGgaJpZM4Jh_HK
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I don't know if this is related but in the backend, I have experimented a weird issue with the mod LOGGED - IN USERS that works haphazardly. Once it works correctly, another time it displays 0 while 2 admins are working on it!

screen shot 2016-08-19 at 07 18 21

@brianteeman @mbabker @C-Lodder @MATsxm is there a good reason why this module DOES NOT utilise ajax?

What's the need to use AJAX? Unless you're looking to increase resource use and have it dynamically refresh on every user login/out transaction it's fine as is (loading a snapshot based on when the request was made).

My idea was to move it to cpanel AND use ajax, as I find it an extra clutter at the moment as is. In fact all that footer/status thing I think should be removed and all the elements should be displayed/moved to the cpanel. Having the link to the front end published both at the top and the bottom smells bad UX/UI

We are talking about the module on the front end NOT the admin!!!

On 19 August 2016 at 14:05, Dimitri Grammatikogianni <
notifications@github.com> wrote:

My idea was to move it to cpanel AND use ajax, as I find it an extra
clutter at the moment as is. In fact all that footer/status thing I think
should be removed and all the elements should be displayed/moved to the
cpanel. Having the link to the front end published both at the top and the
bottom smells bad UX/UI

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11556 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8UftRJINLdMbui_946cXlGuXp0dCks5qhaolgaJpZM4Jh_HK
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@dgt41 - I can't imagine how using Ajax for this would be allowed in Joomla, as it will eat server resources. But either way, let's stick to the main issue and try and figure out what's happening with users not appearing to be online

Hi all,

I'm seeing what seems to be a similar problem - but for slightly different reasons.

I'm running a Joomla site but with additional non Joomla / non PHP software that runs alongside it with a home grown single sign on (SSO) solution bridging the two.

The other software runs on the same cookie domain as Joomla and "knows" the name of the Joomla session cookie.
Therefore, on HTTP requests to the APIs that make up the other software, it can look for the presence of the Joomla session cookie.
If that cookie is found in the request, then the Joomla #__session table is queried by the other software using the value from the Joomla session cookie against the session_id column.
If that value is found in the #__session table and the value of the guest column in not 1, then the other software believes that the user is logged on to Joomla and responds appropriately.

This all worked fine for several years until the 3.6.1 release of Joomla.
It still works on 3.6.1 and .2 for a Joomla user who actively logs on and off to Joomla each time. The new value for the Joomla session cookie is seen in the cookie and in the #__session table.

However, it has stopped working for "Remember Me" functionality since 3.6.1 (if my memory serves correctly).

What I'm seeing in the #__session table is mostly reflected in what is detailed above in that I can see (in the Joomla GUI) the "remember me" user who comes back to the site in a new browser session is auto logged in to Joomla and I can see that they have a new entry in the #__session table.
The issue that is causing me problems is that the new session has guest column value as 1. So I ignore that row (as I believe Joomla creates a row in the #__session table even for non logged in / bot users?).

While I'm OK in a few programming languages, PHP isn't really one of them so I've haven't gone delving through the Joomla source code too much. What confuses me even more is how Joomla is working OK given this data for the guest row in the #__session table for the "remember me" user.

As a test, I reverted the plugins/user/joomla/joomla.php file to a version prior to 3.6.1 and the behaviour of the "remember me" user changed back to what I previously expected i.e. a "remember me" user has a row in the #__session table with a guest value of 0. I note that previous versions of the code included
$query = $this->db->getQuery(true)
->update($this->db->quoteName('#__session'))
->set($this->db->quoteName('guest') . ' = ' . $this->db->quote($instance->guest))
->....
but, as above, I'm no PHP developer.

If this isn't the same problem, please accept my apologies for "spamming" this thread!

And "thank you" for the great free Joomla software.

Check issue: https://issues.joomla.org/tracker/joomla-cms/11691

In my case I get correct results in Kunena

The fix at https://issues.joomla.org/tracker/joomla-cms/11691 also resolves the problem I detailed above. Many thanks.

Set to "closed" on behalf of @zero-24 by The JTracker Application at issues.joomla.org/joomla-cms/11556