Bug in Instructions? Sessions and Sentinel

Posted: Tue Aug 30, 2005 1:32 pm

See end of thread for possible bug discussion.

I have a Nuke 7.4 system that I just installed Sentinel on yesterday. Also, I run Approve Membership within Nuke system. I have a little ad hoc program that I run that tells me who is logged on ... it looks in the Nuke Sessions file and takes the user name from nuke_sessions and matches it to the nuke_user table and formats a little display for me. I'll contribute it at the bottom.

Anyway, after installing Sentinel I've noticed I had a lot less users in sessions and a lot more guests. After testing locally I've come to the conclusion that something is happening where a user logging in is getting sent to the userinfo function in the /your account/index.php file more frequently, probably because of the value of $bypass being set to "1" if there are still cookies for that user. The login and logout functions reset the values in sessions, adding new users as active and deleting them when they leave so this behavior leaves the nuke_sessions file kind of inconsistent if not useless.

I noticed on the Ulsoft forums that there were slightly different edits for the Nuke Sentinel /your_account/index.php with and without Approve Membership but that was an older version than mine and the edits don't match up with the code I now see. I will keep digging but I'm just wondering if anyone else has encountered these problems and better yet has found a solution.

Oh here's the code I use if anyone can use it, at your own risk of course. I just run it from an adhoc directory I have:

Code:

<?php


// require_once("../mainfile.php");


 require_once("../config.php");


    require_once("db.php");


   $sql2 = "SELECT uname, host_addr FROM ".$prefix."_session";


   


   


//   echo $sql2 . '<BR>';


   $result2 = $db->sql_query($sql2);


    $sessions = $db->sql_numrows($result2);


    echo 'Number of records in sessions = ' . $sessions . '<br>';


    echo '<table cellpadding="4" border="1">';


   while ($row = $db->sql_fetchrow($result2)) {


      $username = $row['uname'];


      $host = $row['host_addr'];


      // $guest = $row['guest'];


      $sql3 = "SELECT * FROM ".$prefix."_users WHERE username = '$username'";


      // echo $sql2 . '<BR>';


      $result3 = $db->sql_query($sql3);


      $row3 = $db->sql_fetchrow($result3);


      $email = $row3['user_email'];   


      $name = $row3['name'];


      $id = $row3['user_id'];


      echo "<tr><td align=\"right\">$host</td><td align=\"right\">$email</td><td align=\right\">$name</td><td align=\"right\">$username</td><td align=\"right\">$id</td></tr>";


      }


   echo "</table>";


?>

Posted: Wed Aug 31, 2005 11:51 am

Result(s) of digging ... problem not solved but ...

In the mainfile.php in the function online the value of cookie[1] only appears to be correct immediately after the /your_account/index.php is run. If you execute mainfile from home or any other module there does not appear to be a value set in cookie. Here's the code I am using to test:

Code:

function online() {


global $user, $cookie, $prefix, $db, $nsnst_const;


echo '<table bgcolor=white>


<tr><td>online:  nsnst remote client ' . $nsnst_const['remote_ip'] . ' ' . $nsnst_const['client_ip'] . '</td></tr>';


echo '<tr><td>online: user ' . $user[0] . ' ' . $user[1] . '</td></tr>';


echo '<tr><td>online: cookie ' . $cookie[0] . ' ' . $cookie[1] . '</td></tr></table>';


  if(!file_exists('includes/nukesentinel.php')) {


   echo '<table  bgcolor=white><tr><td>' . 'online: not file exists nukesentinel.php'  .                           $uname . '</td></tr></table>';


          $ip = $_SERVER['REMOTE_ADDR'];


  } else {


    $ip = $nsnst_const['remote_ip'];


   echo '<table bgcolor=white><tr><TD>' .  'online: file exists nukesentinel.php' . $uname . '</td></tr><tr><td>online: value of cookie1 is ' . $cookie[1] . '</td></tr></table>';


  }


        


    $uname = $cookie[1];


   echo '<table bgcolor=white><tr><TD>' .  'online: uname ' . $uname . ' cookie ' . $cookie[1] . '</td></tr></table>';


  


    if (!isset($uname)) {


/*         $uname = "$ip"; */


           $uname = $ip;


           $guest = 1;


   echo '<table bgcolor=white><tr><TD>' .  'online function of mainfile not isset(uname) -- uname and cookie' . $uname . ' ' . $cookie[1] . '</td></tr>';


   echo '<tr><TD>' .  'file exists nukesentinel.php' . $uname . '</td></tr></table>';


    }


    // $past = time()-3600;


   $past = time()-60;

I wasn't sure about the functionality of the quotes around $ip but it doesn't seem to matter. I set the time lower so I could see if _sessions was getting cleared.

Here is a screen capture when I come in from any module but your_account:

Quote:

online: nsnst remote client 127.0.0.1 none
online: user M j
online: cookie
online: file exists nukesentinel.php
online: value of cookie1 is
online: uname cookie
online function of mainfile not isset(uname) -- uname and cookie127.0.0.1
file exists nukesentinel.php127.0.0.1

and here is what happens when I run your_account:

Quote:

cookiedecode: 2
userinfo: fkelly
userinfo: cookie 0 2 cookie 1fkelly
cookiedecode: 2
online: nsnst remote client 127.0.0.1 none
online: user M j
online: cookie 2 fkelly
online: file exists nukesentinel.php
online: value of cookie1 is fkelly
online: uname fkelly cookie fkelly

The things before the colons are the functions that the program is in when I "print" the results. What appears to be haywire is that the cookie isn't set except after coming directly back from your_account and therefore $guest gets set to "1". I just don't see where anything gets unset.

Except me: I've very unsettled.

Posted: Wed Aug 31, 2005 3:46 pm

Well I've been digging. Here are the instructions from mainfile7.4.txt: in function function online()

Quote:

{
#
#-----[ FIND ]------------------------------------------
#
function online() {
global $user, $cookie, $prefix, $db;
$ip = $_SERVER['REMOTE_ADDR'];

#
#-----[ CHANGE TO ]------------------------------------------
#
function online() {
global $nsnst_const, $user, $cookie, $prefix, $db;
if(!file_exists('includes/nukesentinel.php')) {
$ip = $_SERVER['REMOTE_ADDR'];
} else {
$ip = $nsnst_const['remote_ip'];
}

I dutifully followed them. Since I've been chasing down the anomaly in _sessions that results. It was driving me totally nuts. I had all sorts of "traces" in, although you apparently have to "roll your own" with PHP. Finally I decided to bring back an old version of mainfile, before Sentinel and just see what happened. Just looking at it, there is a cookiedecode() statement right after the function declaration.

From the "old" version of mainfile before sentinel.

Code:

function online() {


    global $user, $cookie, $prefix, $db;


    cookiedecode($user);


    $ip = $_SERVER["REMOTE_ADDR"];


    $uname = $cookie[1];

I haven't totally tested whether this fixes everything but before anyone wastes any time on this I just wanted to post it. I suspect that the instructions are incorrect but I admit to limited knowledge and experience. One of the moderators might get to this and give us a more authoritative opinion.

registered · Posted: Tue Sep 20, 2005 9:19 am

Code:

/************************************************************************/


/* This file is for instructional use.                                  */


/* By: NukeScripts Network (webmaster@nukescripts.net)                  */


/* http://www.nukescripts.net                                           */


/* Modifications Copyright ï¿½ 2000-2005 by NukeScripts Network           */


/************************************************************************/


/* Based on Patched 3.1 mainfile.php your mainfile.php may differ from  */


/* the examples found here.                                             */


/************************************************************************/

The Core file edits examples are based on Patched 3.1 which your mainfile is not a Patched 3.1 mainfile.php . The Patched 3.1 mainfile.php has the following:

Code:

function online() {


  global $user, $cookie, $prefix, $db;


  $ip = $_SERVER['REMOTE_ADDR'];


  $guest = 0;


  if (is_user($user)) {


    cookiedecode($user);


    $uname = $cookie[1];


    if (!isset($uname)) {


      $uname = $ip;


      $guest = 1;


    }


  } else {


    $uname = $ip;


    $guest = 1;


  }

If you notice the cookiedecode is in the if(is_user($user)) conditional statement. We didn't omit anything in the edit. For us to have omitted the cookiedecode it would have to have been in the "FIND" but not in the "REPLACE" sections. We are only telling you how to have the sesions table store the correct real ip. At the begining of the text file we state:

Code:

/************************************************************************/


/* Based on Patched 3.1 mainfile.php your mainfile.php may differ from  */


/* the examples found here.                                             */


/************************************************************************/

your mainfile.php may differ from the examples found here, we count on people reading that line and understanding that we are providing one sample not a solution to every possible situation.

Posted: Wed Sep 28, 2005 3:27 pm

Thank you for replying and of course you are correct. My mainfile was not a 3.1 patched version. All of my Nuke files had the following:

/* Additional security checking code 2003 by chatserv */

And I didn't realize that there are different levels of patches that chatserv has issued and the latest of them was in July 2005. I sure do now and will be installing them asap. Since I've installed Sentinel 2.4 I've looked at options and it seems like the easiest and most reliable route is to install the 3.1 patched files and then go back and re-do the core file edits. There are a lot less core file edits than there are changes in the 3.1 patch. Also, for those who have Approve Members installed it appears that there is a 3.1 patched version of that available at Ulsoft -- this would avoid trying to interweave the 3.1 patch changes into the your_account index.php file which is changed extensively by the Approve Members module.

Looking at the forums I don't think I'm the only one who didn't realize that he didn't have the 3.1 patches. Perhaps where you have:

Quote:

* Based on Patched 3.1 mainfile.php your mainfile.php may differ from */

in your text file, you could add something to the effect that the Patched 3.1 was issued in July 2005, can be found at nukefixes.com and you should verify that it is fully installed before proceeding to make the core_file edits. I know that you should be able to count on a reasonable level of intelligence from your users and I guess that I fall short on that count, but I suspect that I'm far from the only one who needs protection from his own shortcomings.