Will Munny

This appears to have changed in the latest version. There now appears to be only one place to make the edit. The 'PT30M'. Is this a safe edit, are there any gotchas I may have missed?. . .

/applications/core/widgets. . .

		/* Do we have permission? */
		if ( !\IPS\Member::loggedIn()->canAccessModule( \IPS\Application\Module::get( 'core', 'online' ) ) )
		{
			return "";
		}

		$where = array(
			array( 'core_sessions.running_time>' . \IPS\DateTime::create()->sub( new \DateInterval( 'PT30M' ) )->getTimeStamp() ),
			array( 'core_groups.g_hide_online_list=0' )
		);

 

Is this the session.gc_maxlifetime setting?

​System --> Applications --> System --> Online User List

Thanks. That gave me a white screen unfortunately. However, I've now realised there's a group permissions setting in ACP to hide the online users from specific groups altogether.

Yes you're right, thanks for the pointer. There were two references to the 30 minute limit in that file you mentioned and changing them both (one for members, one for guests) appears to work. . .

        /* Get Members */
        $members = iterator_to_array( \IPS\Db::i()->select( array( 'member_id', 'member_name', 'seo_name', 'member_group' ), 'core_sessions', array(
            array( 'login_type=' . \IPS\Session\Front::LOGIN_TYPE_MEMBER ),
            array( 'running_time>' . \IPS\DateTime::create()->sub( new \DateInterval( 'PT90M' ) )->getTimeStamp() )
        ), 'running_time DESC', $this->orientation === 'horizontal' ? NULL : 60 )->setKeyField( 'member_id' ) );
        
        /* Get guests count */
        $memberCount = 0;
        $guests = 0;
        $anonymous = 0;
        if ( $this->orientation === 'horizontal' )
        {
            foreach ( \IPS\Db::i()->select( 'login_type, COUNT(*) AS count', 'core_sessions', array( 'running_time>' . \IPS\DateTime::create()->sub( new \DateInterval( 'PT90M' ) )->getTimeStamp() ), NULL, NULL, 'login_type' ) as $row )

Safe???

Also, There appears to be no setting to make this box only available to members. Do you have any advice for me on how to hide it from guests?

Actually it seems you also have to edit the following line to make it work. . .

		$table->limit = 30;

That also makes the online users page much bigger or smaller though (depending on which way you edit the limit). I actually prefer to see bigges online users pages.

Any devs got some input for this?

I think I figured this out myself. In /applications/core/modules/front/online. . .

        /* Initial filters */
        $where = array(
            array( "core_sessions.running_time>?", \IPS\DateTime::create()->sub( new \DateInterval( 'PT30M' ) )->getTimeStamp() ),

If I change the 'PT30M' to something like 'PT15M' or 'PT90M', it appears to work. Is this a safe edit?

Is this a file edit? I'm happy to edit a file to make this happen. . .

How do I change this? It appears to be set at 30 minutes. How to adjust this? I can't see anything in ACP.

I hope there'll be a skin changes instructional. This will be the first time I'll try that updating method. I had a server HDD failure this week that cost me a whole lot of time to rebuild my system to spec (plus 10 hours forum downtime. Last thing I need is an IPB upgrade :D

If you want to test whether or not your server is outputting gzipped content properly, there are online tools a'plenty... try this one: http://www.whatsmyip.org/http_compression/

Yes. You won't break anything by leaving it switched on in ACP, but with Deflate active in Apache, EVERYTHING served up from your server is gzipped already, regardless of the settings in ACP.

Hmm not sure i understand. :) You are giving me an adivce to install csf? :) Or maybe i didnt understand... :D

Well, I'm assuming you want to get your server tuned up in general... and that includes rock solid security to keep out unwanted spiders and scrapers, which hog resources, sometimes badly. If you've just got yourself an UNMANAGED server, PHP will be set to all it's default values i.e. wide open to attack, back door placements, this that and the other... you need to close up the cracks immediately. Apache/Linux comes with it's own firewall built in and configserver's plugin is a nice addition to your server as a graphical interface and automated system to detect attacks and block them. It also downloads things like the Spamhaus lists so it's up to date on the latest threats. You can just set it up and forget it... I went online with my server without the firewall switched on to see what would happen. Thousands of bots online, all of them bad bots. Getting your firewall set up nicely is key to saving your resources for those that deserve it i.e. your real human visitors.

Hmmm... Installed apc? :huh: We tried with memcache. But, there is a page "apc.php" that you can put on your server so it shows apc stats, also we found memcache.php page but it was always showing like 99,9% free and 0,01% was cached... :huh: What i want to say is that we didnt know if memcache was working at all... :(

As I alluded to above, at this time I'm more concerned that you're running a default PHP set up... do some Googling for 'Harden PHP' and you'll see lots of advice and tutorials.
Look at it like this: Put the plug in the plug hole before filling the bath with water.

What measures have you taken to harden up your PHP?

If you're running cPanel, you could do a lot worse than installing the configserver plugin to manage your firewall. Although their install services are available for a fee, it's actually free software and if you're confident enough, you can install it and set it up on your own...
http://www.configserver.com/cp/csf.html

... advice given humbly with no sense of superiority :blink:

Did you read my tutorial on changing to UTF-8?... It's not a database converter but it details the exhaustive steps required to be truly running in UTF-8... and many people probably won't need to make the conversion if you take these steps. In fact, you may decide that running a converter on your database is not worth the risk, unless your board's primary language is in a complex script...

After making the changes detailed in my tutorial, everything posted thereafter will work fully and properly in UTF-8, no matter what the language...
Making the switch to UTF-8

So I can just change...

$url	= preg_replace( "/s=([a-zA-Z0-9]{32})(&|&)/", '', $url ) . '&s=' . $matches[1];

to...

$url	= preg_replace( "/s=([a-zA-Z0-9]{32})(&|&)/", '', $url ) . '&s=' . $matches[1];

I just tested and now everything validates perfectly. Is this safe? Is it really as elementary as this?!!

Is it template level or core level patch?... I ask because I'm trying to find it too :D

Also, I just checked my php.ini file and I already have this in place. Further, session.use_trans_sid is off by default in my installation. So, I really don't know why I'm having this issue.

Splendid, thanks... what are the downsides of removing session URL's altogether?

Well I'm only seeing this after upgrading. Previously I had every topic page valid. Now I get hundreds of ampersand erros in cookie session id's...
My browser doesn't display the cookeis but automates services, such as bots, validators, header checkers etc etc are seeing the sessions and the invaliud code.

Oh no!!!... I also just noticed that 301 redirects are going to the session ID version of the URL... for example...

/forum/12345-topic-title/page__s__18f0cce8a945cc9980a542 f6209171c0

Better still, here's a screengrab...

I previously had my board 100 percent valid code... but I just upgraded to 3.0.4 and I get hundreds of errors. Most of them seem to cascade from an unescaped ampersand in session ID... eg...

…e&module=global&section=login&s=128379128371'

Where can I fix this?