Dragonfly CMS v9 ⇒ PHP-Nuke :: Archives ⇒ Access Denied errors on upgrade :: Archived ⇒ Community Forums ⇒ CPG Dragonfly™ CMS
Forum Index Switch from X to Dragonfly v9 PHP-Nuke ⇒ Archives

Archived ⇒ Access Denied errors on upgrade

Hello all. After numerous SQL Injection attacks on my web site, I have finally made the switch to Dragonfly. My problem now is, constant Access Denied messages for every page.

Now, this is going to turn into a very long and sad tale of bug hunting so bear with me. Oh, the site is www.cartel-inc.com

1. I cleaned up after the SQL Injection hack. (Frikkin script kiddies man, not enough bullets in the world.)

2. I installed Dragonfly into a test directory with a test DB to make sure it would run on the server. Everything was peachy (but no GD :()

3. I upload the Dragonfly files to the main site, overwriting all the Nuke crap that was in there. Note: I didn't remove all the extra modules we had installed. We have Freehosting, Nuke Treasury, Sentinel, Nukecast and Google ads.

4. I run an upgrade install and make a new admin account, no worries.

5. I log in as admin (log in screen displays just fine) and all I get is a very plain "Access Denied" message.

6. I deactivate all blockas and modules. No changes.

7. I check that the Dragonfly version of the blocks and modules are inserted into the database and active. No change.

8. I change the default theme, no change.

9. I start putting debug messages all throughout the php files on the server to track down the exact line that is throwing the Access Denied message. The trail goes cold, it look like this:

/admin/modules/index.php - Heres where we start, required once by the admin.php page of course. It requires once on the header.php file.

/header.php - This one does a whole bunch of stuff. One of these things is call its' own head() function which in turn calles the themeheader() function.

/themes/cpgnuke/theme.php - The themeheader() function is in this file it would seem. Once it has been called it does a bunch of stuff and then calls blocks('left')

/includes/functions/display.php - And so we come here to call blocks(). It does some stuff and then the trail goes cold.

This is the last bit of code executed in the script:
if ($count) {
return (isset($blocks[$side]) ? count($blocks[$side]) : 0);

I have echo statements after this line in that block and after that block and they domn't go off. I've put echo statements all along the call stack to catch the execution path coming back from that return statement, nothing. For some reason, after a few passes through this return statement, the execution goes somewhere I can't trace.

I've also tried switching the main site to the test database in case the script kiddie had left a surprise I hadn't noticed. This didn't work either, somehwere in the php code an Access Denied is getting thrown and I can't track down ehre that might be.

I'm at the stage now of deleting all php files, but trying to preserve my coppermine gallery and uploads directory, and reuploading Dragonfly totally clean.

But if someone can give me a hint on how to trace the execution path from that return statement, that would be preferable.

OK, that was a good one. I look forward to your wisdom ladies and gents.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):

Cleared your browser cookies?

Also check your $prefix_admins table is intact - Dragonfly has a different admin structure to phpnuke.

All admin modules will check for is_admin() or can_admin(), else die('Access Denied').

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):

You're a champ Phoneix. Thanks for the speedy reply.

Yep, I cleared cookies and tried again. No change.

I actually cleared out the admins table completely because of the hack attack. I made a new Super user from scratch. No Change.

I had debug code on is_admin and can_admin and it always came back 'True' and 'Super' multiple times, so I don't think that's it either.

Something else I tried was finding all instances of 'Access Denied' in the code and putting individual tags on each one to try and fine exactly which one was firing. No clues from that either.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):

hmmm, and your account default theme is definitely set to cpgnuke?

Having the old phpnuke theme set has proven to cause this problem before.
(admin Access Denied comes up a lot in search)

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):

Yep, definitely cphnuke theme. Don't forget, I also linked into the test site Database which is a completely clean install, no settings changed at all. Still says Access Denied, which tells me there is a php file not liking something or other, probably in an extra Nuke module I installed in the past.

The trick is tracing the call stack back to the exact line of code that does a 'die()'.

I may have to set up php debugging with eclipse on my local machine to find it off a full site backup. I really don't want to have to go through that.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):

I thought you had disabled all modules?

If not, deactivate all non-DF blocks and modules and ensure you comment out any included files you may have in areas like footer and counter. Then re-activate one by one until you find your problem.

On odd occasions there have been issues with the files in the redundant admin folders (case and links).

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):

Oh yes, it's all switched off, which is what is really doing my head in. But I'll delete case and links and see what happens.

Thanks for all your time BTW.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):

OK, the plot now thickens

I delete /admin/case and /admin/links and I get this message instead of the Access Denied:

Fatal error: Call to a member function on a non-object in <snip>/includes/classes/cpg_adminmenu.php on line 209

Now I have something to track again.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):

hmmm, not all the files were redundant, like adlnk_main.php Smile
It contains the core link information, whilst other DF module links are self-contained with the modules themselves.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):

Excuse my exuberance but


Heres the naughty nugget

$linksdir = dir('admin/links');
while($file = $linksdir->read()) {
// CPG-Nuke system PHP-Nuke system
if (preg_match('/^adlnk_.*?\.php$/', $file) || preg_match('/^links\..*?\.php$/', $file)) {
// Dragonfly system
$linksdir = dir('modules');
while($module = $linksdir->read()) {
if (!ereg('[.]',$module) && $module != 'CVS' && file_exists("modules/$module/admin/adlinks.inc")) {

In the file from the error message above. Calling old cpg nuke code for god knows what reason, most have been some setting somewhere. Good news is, I'm back up.

Phoneix, I am so gay for you right now. It's been over a week of lost evenings elephant tracking this bugger.

You're a little Aussie bottler.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):

The code is there for backwards compatibility for some of the older phpnuke and cpgnuke modules, but all DF modules and the better third party modules rely on the newer structure.

Glad you finally nailed it Smile

Now your fun begins - Dragonfly runs with register_globals off, so many of your phpnuke modules with have issues Sad

But it's a helluva lot safer.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):

Yep, half my links aren't working, the admin menus aren't even there. How does DF choose that code block for backwards compatibility? Gotta be some setting somewhere.

Turn over one stone and all you find, is more stones.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):

All times are UTC