11
dejadingo
PRECHECK resursion in protector
  • 2014/12/15 0:36

  • dejadingo

  • Just popping in

  • Posts: 67

  • Since: 2004/10/22


Here's one I did not expect to find.
I'm testing out a new site using Xoops 2.5.7.1 (PHP 5.4.27) and I have installed the Common Utilities (2.2.75) so that I can try out bitcero's QuickPages. The problem I have encountered comes when you try to hide the Common Utilities module from the Main Menu. In the protector's precheck.inc.php we find:
require_once dirname(__FILE__).'/precheck_functions.php' ;

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

  
define('PROTECTOR_PRECHECK_INCLUDED' ) ;

When I hide other modules like User Profile, or Private Messaging, it does not appear that the Database class exists, so we turn on PROTECTOR_PRECHECK_INCLUDED, and proceed with the rest of the code in that file. When hiding Common Utilities, the Database class apparently exists, and we try to load the postcheck.inc.php file. Unfortunately this starts an infinite recursion because PROTECTOR_PRECHECK_INCLUDED has not yet been defined and we go back to loading precheck.inc.php.

If I change precheck.inc.php to move
define('PROTECTOR_PRECHECK_INCLUDED' ) ;
above the check for the Database class, this gets the flag set before we need it to prevent the resursion.



12
dejadingo
Calling XoopsModule->getAdminMenu() from multiple files
  • 2009/1/2 0:17

  • dejadingo

  • Just popping in

  • Posts: 67

  • Since: 2004/10/22


I've been working on CPanel themes over the holidays, and here is an issue that's caused me a lot of headaches and for which I finally isolated the source.

If you create module instances with code from different files while you are building a CPanel theme, the first call to getAdminMenu() for a module will return the menu, but subsequent calls *from different files* will always get an empty menu.

This is happening because the second time you call the method, PHP knows you have already loaded the module's adminmenu file and does not load it again. However, when a module instance is being created and initialized in a different file we need to load the adminmenu file in order to get the $adminmenu array with which to initialize the adminmenu property of the module.

I noticed that MusS seems to have tripped on this issue in his lovely ThAdmin module, but the patch at the end of xoops_thadmin_cp_header() was not sufficient to fix my problems. I really think this is a bug in the XoopsModule class, and it makes incremental development of CPanel themes very difficult. Here's the hack I am currently using on my systems. It's a simple change, and I'd like to hear if anyone thinks this should *not* be generally adopted for the XOOPS core.

/**
     * Load the admin menu for the module
     */
    
function loadAdminMenu()
    {
        if (
$this->getInfo('adminmenu') && $this->getInfo('adminmenu') != '' && file_exists(XOOPS_ROOT_PATH.'/modules/'.$this->getVar('dirname').'/'.$this->getInfo('adminmenu'))) {
// -DJD-
//
//        Make sure we actually load the module's menu (if there is one).
//
//        Using 'include_once' prevents menu initialization when subsequent
//            calls to getAdminMenu() are made from within independent files
//            during the same execution.  A good example is when CPanel menu
//            construction is shared between methods in the XoopsSystemGui
//            subclass and functions in an included cp_functions.php file.
//        PHP loads the file in the context of the first call, but since new
//            instances of XoopsModule are created for use in each independent
//            file's functionality, all subsequently instantiated XoopsModule
//            instances do not have an adminmenu.
//
//            include_once XOOPS_ROOT_PATH.'/modules/'.$this->getVar('dirname').'/'.$this->getInfo('adminmenu');
            
include XOOPS_ROOT_PATH.'/modules/'.$this->getVar('dirname').'/'.$this->getInfo('adminmenu');
//
// -DJD-
            
$this->adminmenu =& $adminmenu;
        }
    }



13
dejadingo
Re: Blocks in wrong order for ANON USERS ONLY on top page after 2.3.2a upgrade
  • 2008/12/19 5:56

  • dejadingo

  • Just popping in

  • Posts: 67

  • Since: 2004/10/22


Thanks so much for finding this. It's certainly an obscure SQL issue, likely due to the WHERE clause construction [WHERE m.block_id=b.bid].

Whoever fixes Tracker issue #2414383 should probably make the same change in line 471 since it has an identical WHERE clause in line 491. I don't have access to update the Tracker issue.



14
dejadingo
Re: Group Permission management and Xoops 3
  • 2008/6/8 16:05

  • dejadingo

  • Just popping in

  • Posts: 67

  • Since: 2004/10/22


OK. So nobody else is currently working on this, but you consider it an appropriate possible core extension?

I know it's not officially blessed, but are there enough people using the 2.3.2 branch that simple sites reasonably might use it? I can put that up on my test site, but it will probably get more action if I put one of my sites up using it instead of the 2.0.18.1 that is currently running.

Thanks, I'll keep watching for XOOPS 3 tarball.



15
dejadingo
Re: Group Permission management and Xoops 3
  • 2008/6/8 15:42

  • dejadingo

  • Just popping in

  • Posts: 67

  • Since: 2004/10/22


Sorry. I just edited my post. I'm talking specifically about group permissions here.

There are several modules that go to extreme lengths to provide their own module specific group permission settings, with onInstall SQL inserts and by cloning system files and tweaking them. myAlbum-P is one of them. I want to provide a standard mechanism for
1) adding a module's permissions without the file cloning, and possibly without the onInstall by extending the $modversion array
2) plugging the management of these permissions into the system-wide group permission management

In addition, I want to use config option categories for my own modules and give permission to specific user groups for certain categories. xfguestbook contains a start on the config categories issue, and I have a hack that I can use to plug that into the standard xoops_version.php file in XOOPS 2.2. But even that does not address my desire to permit the categories for only certain groups.

Thanks.

---
Any info on access to the XOOPS 3 code?



16
dejadingo
Group Permission management and Xoops 3
  • 2008/6/8 15:09

  • dejadingo

  • Just popping in

  • Posts: 67

  • Since: 2004/10/22


I've been running non-portal sites for friends the past several years, and I selected XOOPS because I could easily create my own modules and provide an Admin back end they could use without any programming expertise themselves. It was pretty good when I started, but the improvements provided with the ThAdmin module are fantastic!!!

I've made some additions there that now allow me to plug the tabs into my own module admin pages and my success there has encouraged me to try again to put in some more specific user group permissions, both for preference categories in my modules and for additional module based group permissions.

I've downloaded and researched permissions handling in XOOPS 2.3 but I don't see anything new in this area. So, here are my questions :

1) Is anyone already working on extending the permissions management, either in XOOPS 2.x or in XOOPS 3.0, and if so who?

2) Is there a tarball for XOOPS 3 somewhere that I can download for research, or is it only available through SVN, and if so where is the connection information?

I'd like to talk with anyone else working in this area before I go off and hack it in myself. Maybe we can share work/ideas.

Thanks.



17
dejadingo
Issues related to host provider's server upgrade
  • 2008/2/3 21:42

  • dejadingo

  • Just popping in

  • Posts: 67

  • Since: 2004/10/22


My provider is in the process of trying to migrate everyone to new (supposedly more secure) servers. We use shared hosting, and something else is not an option due to cost considerations for the non-profit organizations involved. There have been several severe impacts of this migration on my XOOPS installations. I have a workaround for one of the problems, but I still have two others that need resolution and I'd like other opinions please. I'll need to look for another provider if I can't find some satisfactory workaround.

Problem #1 (with workaround) -
The provider uses symlinks (or possibly mounts) to manage the physical path for the site's files.

This keeps debug_backtrace() from giving the same path as the path installed in XOOPS_ROOT_PATH. When mainfile.php has this checking turned on (which it is by default) the failed compare results in the message :
"XOOPS path check: Script is not inside XOOPS_ROOT_PATH and cannot run."

I've written the following workaround in mainfile.php to get the site minimally running, but since safe_mode is removed for PHP 6, I'm wondering if this attempt at protection is really too ineffective to bother using at all. What is the real value of this check, and is there any other way to do it?
if ( XOOPS_CHECK_PATH && !@ini_get('safe_mode') ) {

// -DJD- workaround for symlink issues with debug_backtrace()
/* --------------------------------------------------------
        if ( function_exists('debug_backtrace') ) {
            $xoopsScriptPath = debug_backtrace();
            if ( !count($xoopsScriptPath) ) {
                 die("XOOPS path check: this file cannot be requested directly");
            }
            $xoopsScriptPath = $xoopsScriptPath[0]['file'];
        } else {
            $xoopsScriptPath = isset($_SERVER['PATH_TRANSLATED']) ? $_SERVER['PATH_TRANSLATED'] :  $_SERVER['SCRIPT_FILENAME'];
        }
-------------------------------------------------------- */
        
if ( function_exists('debug_backtrace') ) {
            if ( !
count(debug_backtrace()) ) {
                 die(
"XOOPS path check: this file cannot be requested directly");
            }
        }
        
$xoopsScriptPath = isset($_SERVER['PATH_TRANSLATED']) ? $_SERVER['PATH_TRANSLATED'] :
            
$_SERVER['SCRIPT_FILENAME'];
// -DJD- workaround

        
if ( DIRECTORY_SEPARATOR != '/' ) {
            
// IIS6 may double the  chars
            
$xoopsScriptPath str_replacestrpos$xoopsScriptPath'\\') ? '\\' DIRECTORY_SEPARATOR'/'$xoopsScriptPath);
        }
        if ( 
strcasecmpsubstr($xoopsScriptPath0strlen(XOOPS_ROOT_PATH)), str_replaceDIRECTORY_SEPARATOR'/'XOOPS_ROOT_PATH)) ) {
             exit(
"XOOPS path check: Script is not inside XOOPS_ROOT_PATH and cannot run.");
        }
    }


Problem #2 (annoying, but not a show-stopper) -
Xoops creates file names for /cache and /templates_c that FTP clients such as FireZilla and WS-FTPPro are unable to delete from the new server.

Level 2 support at my provider tells me that the legacy platform uses a GRSEC infrastructure whereas the new platform uses LDAP, and that the file names contain characters that are illegal on the new servers. I know what LDAP is, but I'm not a UNIX geek and I can't understand why this would cause the FTP client to get a "550-Forbidden command argument" when trying to delete the file. The provider's web-based File Manager, logged in using the same FTP id/pwd, can successfully delete the files, but it is extremely difficult and time consuming to use.

Can anyone shed some light on what is happening here?

Problem #3 (a potential show-stopper) -
For security reasons, the provider will no longer permit any directories outside of the public_html tree to execute scripts.

This impacts the Protector module, and I'm wondering if there is any point in installing this module if the XOOPS_TRUST_PATH must be inside public_html. Doesn't that defeat one of its primary purposes?

Thanks for any comments or insights you may have.



18
dejadingo
Re: [critical] hosting service turning off allow_url_fopen
  • 2007/12/27 18:10

  • dejadingo

  • Just popping in

  • Posts: 67

  • Since: 2004/10/22


Thanks, especially to Will_H, for the doc pointers. It turns out that the only issue was the one I mentioned, and due to the fact that I used XoopsPartners as a base for my own site-links module.

On to the next porting problem ...



19
dejadingo
Re: [critical] hosting service turning off allow_url_fopen
  • 2007/12/14 22:12

  • dejadingo

  • Just popping in

  • Posts: 67

  • Since: 2004/10/22


No, I don't intend to ask to have it turned back on, even if I could. And no, I don't expect a list of all the modules that once were vulnerable.

I'm glad the XOOPS CORE is not a problem, and I am therefore concentrating on the modules. The list of vulnerable php functions is helpful in that search. Any other such functions someone cares to enumerate would be welcome.

Thank you.



20
dejadingo
Re: [critical] hosting service turning off allow_url_fopen
  • 2007/12/14 20:31

  • dejadingo

  • Just popping in

  • Posts: 67

  • Since: 2004/10/22


Yes, it's *obvious* this is a good thing in terms of hacker protection. However, there are certainly issues with PHP code that will not work, or works differently, with allow_url_fopen truned off. And I'm certainly not golden here.

Here's one thing I've found already, and I'm sure more will follow as I test every single piece of every single page, both user and admin functionality.

The PHP function getimagesize() will not accept a URL, even one that is within my own site. This affects (at least my version of) XoopsPartners 1.1.

Perhaps all the various calls to fopen() in the system are benign, but I will have to check them also.




TopTop
« 1 (2) 3 4 5 ... 7 »



Login

Username:
Password:

Lost Password? Register now!

Who's Online

82 user(s) are online (54 user(s) are browsing Support Forums)


Members: 0


Guests: 82


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Nov 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits