Users can't stayed logged in, and errors on YA page

Posted: Sat Aug 26, 2006 7:48 am

Guardian: are you looking on his roughingthesuspect.com site? See where it says "this is the password returned from the user table:" and then it's blank. Do you see anything wrong with my code that would cause it not be be returned if it existed? I'm thinking that's causing the is_user function to return a negative leading to navbar not to be included.

Schwim: if you have phpmyadmin just go in and select the users table. Browse it. Select the record you want to edit and choose edit. The fields will come up for editing. In the functions drop down box pick md5 and then type in the text that you want to use as a password. Phpmyadmin will apply the md5 function to the text and make an encrypted password for you. While you are in there you can verify that the records exist and that there are passwords in there. What you were listing in there earlier for the admin id for the password should be in the file (i.e., 5f4dcc3b5aa765d61d8327deb882cf99) but if it is then I'm puzzled why it's not echoing back out.

Hangin' Around Joined: Feb 28, 2006 Posts: 38

Hi there fkelly,

The data for the admin password WAS in the database correctly, I got the actual data in my last post by viewing it through phpMyAdmin.

So, the data is in the database, it's not being passed through to the echo.

this sucks, man...
json

Posted: Sat Aug 26, 2006 12:53 pm

Sorry again Schwim.

There is something wrong here. I just put the same echoes into my test system at fkelly.org and in the line that I quoted before:

Code:

 echo 'this is the password returned from the user table ' . $row[0] . '<br>';

it is showing the password. But on your test site this is blank. Look at the block of code where this occurs:

Code:

if (!empty($uid) AND !empty($pwd)) {


        global $db, $user_prefix;


        $sql = "SELECT user_password FROM ".$user_prefix."_users WHERE user_id='$uid'";


        $result = $db->sql_query($sql);


        $row = $db->sql_fetchrow($result);


        echo 'this is the password returned from the user table ' . $row[0] . '<br>';

From the earlier echoes we've done we've seen that the variables $uid and $pwd have values in them. So there is something strange happening with the table read or else the password would be echoed back out as $row[0].

The user_id that it's searching for is number 3 as we've seen echoed.

Since you can get into phpmyadmin how about go over there and bring up the users table and go into SQL and try this query:

SELECT `user_password` FROM `nuke_users` WHERE user_id=3

Does that return a result? If so, the only other thing I can think of is that maybe you don't have the user_prefix right and aren't connecting to the table.

Posted: Sat Aug 26, 2006 1:11 pm

Hi there fkelly,

This is what I got:

4b57d50cd514088317d7f46176f3d57b

Please keep in mind that this might not be the right password anymore, because it seems someone logged into that account and changed it. I can no longer log into the test account.

thanks,
json

Posted: Sat Aug 26, 2006 2:00 pm

Hi again Schwim. So the 4b... password is what you see in PHPmyadmin when you run that SQL that I gave you? But there is something strange happening here. Because I went into your site and created an id with the username "Frank" and the 4b... thing is my password, it's what I see in the echoes when I go to your site. But it has the user_id of 3. How many userids do you have in the users table?

Incidentally, the echoes that I have you running will keep the login screen from working because they screw up the security graphic. So you will need to turn them off to login and out between userids. Sorry, but that's a limitation of this approach, I've developed a whole diagnostic block to deal with this problem but it's overkill for this situation I think.

If you want to PM me what I'd need to FTP to this test site and also to get into PHPmyadmin I will look at it; but I am running out of time for today (Saturday). The fact that you are not seeing anything after: "this is the password returned from the user table" is really the key -- if it can't find that then is_user will always return false and the rest of the problems you are seeing will continue to occur.

For the short term, I'd take a good look at the user_prefix and make sure that's right.

Posted: Sat Aug 26, 2006 8:38 pm

Hi there Frank(now I know your name Smile

),

uid2=admin
uid3=frank
uid4=guardian

that's all that's in the users table besides anon.

I've double-checked the config.php, and it seems that everything is as it should be.

Would the changes you made also cause new registrations to fail? When I try to register a new name, it says that it's been taken, but I've checked the db, and there are no extra names in the db. I'm just trying nonsense registration names, and every time it tells me that the nick is already taken.

I'll pm you the info you need.

Again, thank you for your help.

thanks,
json

Posted: Sun Aug 27, 2006 9:11 am

I used the FTP and PHPmyadmin accounts you gave me to work on the problem.

There are now two versions of mainfile on your test server ... on is named mainfile.php and the other is mainfile_echoes.php. The latter has the diagnostics in it but of course it's ugly.

You have a very strange problem which we will need wiser heads than mine to fully solve . Let's look at the code I've revised

Code:

        $sql = "SELECT user_password FROM ".$user_prefix."_users WHERE user_id='$uid'";


//        echo $sql . '<br>';


        $result = $db->sql_query($sql);


//        echo 'number of rows returned: ' . $db->sql_numrows($db->sql_query($sql)) . '<br>';


        $row = $db->sql_fetchrow($result);


 //       echo 'this is the password returned from the user table ' . $row['user_password'] . $row[0] . '<br>';


        $db->sql_freeresult($result);


        if ($row['user_password'] == $pwd && !empty($row['user_password'])) {


            static $userSave;


           return $userSave = 1;

When you do a $row = $db->sql_fetchrow($result) you are supposed to return an array into $row that can be accessed either thru the field name or the array element number. (I think I'm saying that right). So, since you are only looking at one field, user_password, that should be in $row[0]. That works on all the systems that I know of but it doesn't work on yours. All I can think of is that maybe it's a bug with your version of mysql. I changed the code in is_user() to access the field by the field name and now it seems to work. I even temporarily did a select * instead of just the user_password and none of the array element references by position seem to work.

The consequence of all this was that is_user was returning false so navbar wasn't being called etc. like we said before. It just took some time to figure it out.

I believe that the mainfile.php I've left you with will work for this purpose, I seem to be able to go into your account without the navbar error anymore. However, I also believe that there are many other places where Nuke references results by their array element number and if the problem is more generic than just what's shown here in the is_user function you could have problems throughout the system.

I've done some googling around mysql sites to see if there's a known bug related to this but I can't find it. Gotta run now but I hope this was some help. If any of the mysql experts would like to jump in with more help, please you are welcome.

Posted: Sun Aug 27, 2006 1:04 pm

I just used my access to do a little more testing. I tried to access the field name at an earlier place in mainfile where it reads the config table and was unable to use the $row[0] syntax successfully there. So there is something going on that's more generic than just a problem with the is_user() function. I suspect that you'll generally have problems with Nuke until this is cleared up but I don't have a solution except maybe a different server.

I thought maybe the freeresult was causing the problem by it's placement but removing that brought no joy either. I put the program back the way it was after my experiments, so is_user is accessing $row['user_password'] again and the echoes are commented out. It looks like this makes the original your_account problem go away but as I say I think there will be other similar problems until the underlying issue is addressed.

Posted: Wed Aug 30, 2006 7:30 am

Hi there Frank,

I was waiting to reply in hopes that I'd have better news, but I've waited, and it seems none is coming, so I'll tell you what they did say. I posted my problem in a mysql forum, in hopes that they might have seen something like this. They say that it's the wrapper class that I'm using to access the database. I have no idea what that means, but it sounded like they're saying that it's the script's fault.

What are your thoughts in the matter? A faulty php or mysql install? A setting that is wrong on either one? I'd be interested in your thoughts, as I'm at a loss as to what I can do to fix this. I've got about 10 more sites to move over that use php-nuke, and I can't tell you how painful it is to convert php-nuke db's to postnuke. I don't ever want to do it again if I can help it Very Happy

thanks,
json

Posted: Wed Aug 30, 2006 8:00 am

Schwim: if you look in the /db directory you'll see where the "wrapper" class is. You would be using the classes defined in the file "mysql4.php". These should be the same as for every other PHPnuke system or at least the same as for all Ravennuke distributions. I don't believe that these have changed recently. You could try re-ftp'ng these from your Ravennuke distribution but I don't believe it will change anything. Just replace everything in the /db directory from what you downloaded from Ravennuke and see if that helps.

Basically what these wrappers do is "abstract" the details of data base access so that within PHPnuke you can use the same code regardless of which relational database you use.

I don't have time to look at your files this morning but if I get a chance I will look later in the day. Please post here if you replace the files and let us know whether that works. There are other things we can try; for instance you can make a "native" mysql connection and use the native mysql functions and see if you can access row[0]. That would tell you whether it's the wrapper class or something else. We should probably also write some kind of "testbed.php" program that accesses one of the tables several different ways so we can experiment without continuing to change mainfile. I have some adhoc programs we could start with but again I just don't have time to play with it until later.

Posted: Wed Aug 30, 2006 10:58 am

Hi there frank,

I reuploaded everything in the /db directory straight from a fresh zip file, and the problem is the same. Also the fact that it spans more than one version of Nuke makes me think that it's not a corrupt file.

If you're willing to help during whatever time you have available, I would be greatly appreciative. I would very much like to narrow the problem down so I know what is causing it when it happens again.

thanks,
json

Posted: Thu Aug 31, 2006 10:12 am

Schwim: Hello again. I haven't had any time to work on this. I did stumble across one idea though. While experimenting with files in the /db directory I switched from MySQL to Mysql4 in the config.php. That led to the same type of error that you encountered when I went to your_account. So I am just wondering if you have ... well I just checked it and you do ... mysql4 as the database type in config.php. Just give it a try switching that to MySQL and see what happens. Right now we've got the workaround for row[0] in your mainfile (by accessing 'user_password' rather than [0]) but I have the suspicion that if you switch wrappers from mysql4 to MySQL (and the capitalization is important because that's what /db/db.php is looking for) the problem may go away.

What you did in selecting mysql4 is perfectly logical, it just may not work. Sorry to be so rushed in writing this; I just don't have a lot of time right now.

Let us know if you get a chance to try this and it works.

Posted: Thu Aug 31, 2006 11:23 am

Unfortunately there are some problems with using mysql4. Not sure why, but best to use "MySQL"

Posted: Thu Aug 31, 2006 3:41 pm

I think we got it now Schwin. I went in and changed your testbed config.php to point to MySQL and now everything works. I verified it with echoes in and then I took them out of mainfile. I believe that the problem may be that mysql4.php uses a constant (MYSQL_ASSOC) that's not defined anywhere in it's fetchrow definition but that's a topic for another day.

Give it a try in your testbed and then in some of your other systems and let us know.

Posted: Fri Sep 01, 2006 7:47 pm

wow.

I'm not sure yet whether to laugh or cry. I'm kind of in shock. I really thought that it would never get figured out(server problem most probably), so I spent more hours than I care to remember porting the data to postnuke. Now, after changing the config setting on the production site, it works like a complete charm.

I think crying is the way I'm going to go with this.... yep, for sure...

Frank, I can't thank you enough for the help you've given me. If it hadn't been for you, I wouldn't be able to move any of the other sites over, and that alone is invaluable. I appreciate your help immensly.

The mystery of the non-working php-nuke site lies in the fact that the MySQL4 wrapper is flawed. Wow. A lot of trouble could have been saved here, huh? Wink

thanks,
json

Posted: Fri Sep 01, 2006 8:20 pm

Json:

First of all thanks to you also. By having a test site you made it a LOT easier for us to figure out what was going on. I would never have been as "free" to make those diagnostic changes on a production site that enabled us to narrow this down. Plus, the "error" you made (and I don't really think it can be called that) was to use mysql4. Well heck, you are using a version of MYSQL that's a 4 so why wouldn't you? Now it's documented in the threads and others can avoid that. As I'm typing this I'm thinking that we should probably even remove the mysql4.php file from the distribution unless one of the experts here knows of a reason for keeping it. It just looks like a source of problems to me.

Finally, when the dust settles from all this and you get things running I'd encourage you to take a look at the diagnostic process that took place (not that it couldn't be have been done better) and experiment on your own. You can learn a lot by the judicious placement of echo statements on a test system and over time you'll be much better able to figure things out for yourself.

New Member Joined: Jul 05, 2006 Posts: 5

I am having the same problem. Mine is a fresh install of v2.02.02 no added mods.

I did have some trouble with the setup.

I had to delete the .htaccess for my server to not get the error 505

I did not turn on the sentinal admin section due to the only option I had was the CGI one. and I read where the CGI option needed the .htaccess file.

After the first time I got the error I deleted the whole thing and reloaded, but I got the same error as before.

And before anyone says it is listed somewhere else on the forum I would like to say I have been researching this trouble for 3 days now before I wrote this message.