#1286 Perminant Loop with Projector & Preloads with checking for post in pre, memory bloat!

XOOPS_2.5.x
open
nobody
None
1
2014-01-20
2013-08-01
No

In the following file: htdocs\xoops_lib\modules\protector\include lines 5 to 8 neeed to be removed from precheck.inc.php

Post checking runs anyway, if a module intialised the database before the preloader fires for precheck.inc.php in most conditions XOOPS sits in a permant loop until memory limit is release or does WSOD.

Remove the following lines from precheck.inc.php

if( class_exists( 'Database' ) ) {
require dirname(FILE).'/postcheck.inc.php' ;
return ;
}

Discussion

  • Richard Griffith

    Just to be clear, you say "if a module intialised the database before the preloader fires for precheck.inc.php"

    If a module is forcing the database init before protector precheck runs, it is opening a security hole. This sounds more like a bug in the module rather than protector. Since that triggers off of the core.include.common.start event, the database should not have been used before that point.

     
  • Est. Simon Antony Roberts

    I found if a preloader initializes the database before the precheck fires it sits in a permanent loop. It's not really a security hole this part of the precheck is overkill as in most situations the condition it is check never exists.. When it does it sits in a permanent loop and the memory bloats till it crashes.

     
  • Est. Simon Antony Roberts

    No the loop is caused by the preloader firing in circles with other calls with applications. I did a work around by not initialising the database before hand, which limited the application but this was just something I noted was the solution to the logic loop that forms!

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks