Can't login as admin after upgrade

Hangin' Around Joined: May 05, 2006 Posts: 30

Hey there. It seemed to be going so well for me upgrading RN 2.02 to 2.4 but I've run into an annoying issue.

The old admin logins no longer work after upgrading. I can run the setup.php to start over with a new admin, but that way I also lose all the regular users.
What could be wrong? Did the salt/crypting change? Anything I should ensure is identical between the live site and my locally upgraded version for it to work?

Besides that I've been through the usual it seems..

Despite these errors I really like the new Raven release and will donate once I get it working properly. I've had a strange problem with logins completely crashing my local apache server though, so I'm still a bit hesitant to move this upgrade onto the live website.

Thanks in advance to anyone who can help!

Posted: Fri Jan 08, 2010 8:18 am

The encryption on the admin accounts did not change. Nothing on the authors table changed at all. I'd suggest comparing the old to the new in PHPmyadmin. You can see the encrypted version of the passwords and compare them even if you can't decode them.

The encoding issues and there solution have been discussed endlessly in these Forums. You really need to delete the old fckeditor file structure and FTP in the new because the directory structure changed very significantly between 2.02 and 2.4. Likewise the eregi deprecated messages can be easily hidden ... do a search but you basically need to turn display_errors off and/or turn off e_notice.

2.4 is a significant advance over 2.02 and 2.40.01 will be even better. As to your local server crashing ... we really can't help much without further details. It is most likely a local setup issue since there is nothing in the login process that hasn't been tested in a bunch of different environments successfully.

Posted: Fri Jan 08, 2010 9:08 am

Fixed the deprecated thing with "$error_reporting = E_ALL^E_NOTICE^E_DEPRECATED;" in rnconfig.php. Helps me debug my own scripts without all the deprecated clutter.

The admin passwords are still troubling me though.I have imported the admins from the live site and then created a new admin using setup.php.
My 2 admins have almost the same usernames (lowercase a-z chars only) and exactly the same password. Even in PhpMyAdmin the pwd hash is exactly the same. Still it will only let me login as the newly created one.

Having a hard time figuring out what the problem is here.

Posted: Fri Jan 08, 2010 10:10 am

You might need to go into NukeSentinel administration, the httpauth menu there and have it scan for new administrators. There is a nsnst_admins table that needs to get updated, I think.

Posted: Fri Jan 08, 2010 11:39 am

Hmm the nuke_authors table of the live/old (2.02) and the local/new (2.40) are exactly alike including the pwd hashes.

On the local site I tried scanning for new admins in NukeSentinelon Admin and it found the 5 admins I had imported from the live site. However they would still not log in.

The nuke_nsnst_admins table is not similar at all. On the local one the admin I created in setup.php has his password listed in cleartext in the "password" field while the others have a jumbled hash-looking one.
On the live site's nuke_nsnst_admins table no passwords are in cleartext and none of the hashes are equal to the ones of the same admin on the local.

Are there any crypt salts or sitekeys that needs to be the same or am I missing something?

Posted: Fri Jan 08, 2010 1:19 pm

humor me and try editing one of these admin and then see if you can log in. I'm having a really hard time trying to think what might be causing this. I personally do not think it is nuke sentinel related.

Posted: Fri Jan 08, 2010 1:47 pm

is your $sitekey in config.php the same for both?

Posted: Fri Jan 08, 2010 1:52 pm

Now this is strange..
I removed all the surplus admins. The only imported admin left is "banelos-admin"
The other one "banelosadmin" is the one I created from setup.php to be able to log in at all.

Then I changed the password for both to test123 and only the new one would log in.
Created some new admins as well with same password and tested those, they all worked too.

authors table:

nsnst_admins table:

Quite clear from the pwd fields that the password is the same. Yet the banelos-admin author cannot login.
The nsnst_admins table seems strange. Originally only the banelosadmin user had a cleartext password, but I manually changed changed the password in the NukeSentinel auth_list for banelos-admin and test. newadmin was discovered by NukeSentinel but not further changed.

EDIT: sitekey in config.php is exactly the same. Does the Nuke Sentinel crypt salt matter?

Perhaps its better if I just start over from a clean 2.4 database and then import what I can, this is annoying me quite a lot.

Posted: Fri Jan 08, 2010 2:17 pm

LOL! Apparently it was the slash in banelos-admin.
Tried changing the 'aid' in the database to something without a slash.. Now I could log in just fine.
Changed it back and I couldn't log in again.. I feel so stupid now :/

PS. Is it me or does NukeSentinel seems to be easily fooled by a spoofed X-Forwarded-For? I use it to circumvent region-restrictions for US-only content on the web, like The Daily Show, but NukeSentinel thinks my IP is 12.13.14.15 at the moment.

Posted: Fri Jan 08, 2010 2:21 pm

I think it's this code in admin.php that's getting you:

Code:

if (isset($aid) && (ereg('[^a-zA-Z0-9@_.]',trim($aid)))) {


   header('Location: '.$admin_file.'.php');


   die();


}

Unless I am mistaken the dash (-) character won't be found in that ereg and you will just die. Just another case of dumb inconsistency in the software. If we don't want you to use a dash character in a nickname we shouldn't let you register it at all.

Posted: Fri Jan 08, 2010 2:23 pm

Ah okay, thanks for the notice fkelly.
Yes it would have been nice if at least the update script had searched for any admins with any characters not matching that ereg and notified me. But if this wasn't a change from the upgrade to 2.4 I'd say that it's a bug if you can create an admin that doesn't pass that ereg.

EDIT: Definitely a reproducable bug. Try creating an admin with 'test-admin' as name/aid and log in on that admin account.

Posted: Fri Jan 08, 2010 2:48 pm

Yes, I "reproduced" it on a test system before I posted it here. It's really not an issue for the upgrade script ... it is just a bug and inconsistency that I suspect has existed for the life of generic Nuke. A sub-species of the genus "fractured-filtering" if you will.

I have posted this in our issues tracking system for 2.5. For what it's worth I've had a quick look at authors.php that's in the admin directory and I don't see where we do any filtering of the characters that can be in an administrative nickname. The only requirement is that it be 25 characters or less. Most likely the ereg could be eliminated entirely, in fact the whole logic probably should be removed. I was thinking at first that we could check the input and make sure it is 25 characters or less but that's unnecessary. If it's more than 25 characters it won't match a nickname in the authors table anyway.

Posted: Fri Jan 08, 2010 2:51 pm

Yeah the upgrade-script thing was only if it was something that changed in what characters are allowed in admin names from 2.02 and 2.40, but it seems it isn't.

Thanks for looking into this. I will continue to use RavenNuke and am in the midst of updating subBlack to work and look a little better on RN2.4.
I will release it here once it's done so others can benefit from it as well.

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

Just to let you know:

The inconsistency is (also) in the filtering in the installer. The dash is NOT allowed by default. When I set up the installer I used the defaults in RNYA:
define('_rnADMIN_ALLOWED_USERID_CHARACTERS','[a-zA-Z0-9@_\.]*'); //From admin.php, not realizing the eregi issue. What needs to be done is to incorporate the installer configuration rules into the core. In other words, whatever and wherever rules are utilized they need to all pull from a common place.

This will be fixed in the next release which we are working on right now - Version 2.5 Wink