SESSIONS

Posted: Wed Jun 09, 2004 3:14 am

I am at 80-85% of a complete php sessions based admin/user authentication and management.

I have to say that I believe that is the way to go, why store all of this encoded data in a cookie when all you have to do is store a session id that is very rarely ever going to be guessed, hacked etc.

Not to mention creating a much more free flowing and functional environment for nuke in general, any thoughts, I went from around a .4 page gen time to so far a .15 gen time, not too shabby if you ask me.

Sessions allow us to move variables on the fly store arrays, hidden variables etc, where before hidden values would be mounting up inside of forms or URL's (best example is the news module &mode=&order=&thold=blah). The possiblities are limitless, can you tell I'm an advocate Smile

Other than that, I see renaming variable structures and defining a scary word this community likes to ignore and brush off "standard". A variable naming standard that actually defines what type of var it is in the var itself.
Integer $int_id
String $str_title
Bool $bol_check
etc.

That would make grabbing the variables from the $_REQUEST/$_POST/$_GET superglobals very easy because we know exactly which variables need to be which. We clean them and then send them to the file, that would actually cut out having to do this in all files because it is done from the get go (though doing it in the modules would still be good sec practice)

I believe I had talked to CS about something like this long ago (Nov/Dec) timeframe over at NC.

Anyway, I am blabbering yet again, see you all around. Razz

Bill (Audioslaved)

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

Sounds promising! You might find this article interesting as the author disagrees with you on Sessions and will develop it as the days drag on Smile

http://www.devshed.com/c/a/PHP/Building-a-Site-Engine-with-PHP-1/

Posted: Wed Jun 09, 2004 6:46 am

One of my main rebuttals to the author of the article is what is more secure than the actual server to store the variables, we saw how quickly someone was able to figure out the base64_decode method currently being deployed and use it at a great disadvantage to the community.

because of the reliance on cookies the system is also hard as novice developers to add to and change, with sessions it is as easy as declaring a new session variable and later unsetting it.

Code:




if (! isset($_SESSION['Raven_is_our_friend'])) {


$_SESSION['Raven_is_our_friend'] = 1;


} else {


unset($_SESSION['Raven_is_our_friend']);


}

Sessions variables are also instantaneous as with a cookie variable the page must be reloaded before it is set and able to be pulled to and fro.

Because of the way nuke uses cookie's most developers will never set a cookie because they don't know the proper method to pull what already exists and append to or change it and set it back. That makes half of these really great modules lack in the functionality of more commercialized or more mature products. I am not saying we are a commercial product or community, but the look and well thought out-ness of the functionality and general flow is what I am referring to.

A small simple example of how sessions have helped can be demonstrated with a core nuke function: is_user located in the mainfile.php.

From the regular nuke code for 6.5 (Sorry don't have anything more recent lying around)

Code:




function is_user($user) {


    global $prefix, $db, $user_prefix;


    if(!is_array($user)) {


   $user = base64_decode($user);


   $user = explode(":", $user);


        $uid = "$user[0]";


   $pwd = "$user[2]";


    } else {


        $uid = "$user[0]";


   $pwd = "$user[2]";


    }


    if ($uid != "" AND $pwd != "") {


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


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


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


   $pass = $row[user_password];


   if($pass == $pwd && $pass != "") {


       return 1;


   }


    }


    return 0;


}

Same function sessionized

Code:




function is_user($user=0) {


     global $prefix, $db, $user_prefix;


     if (!isset($_SESSION['sessUser_user_name']) OR $_SESSION['sessUser_user_id'] == "1") {


    return 0;


    }


     if (! isset($_SESSION['sessUser_user_set'])) {


          if ($_SESSION['sessUser_user_id'] != "" AND $_SESSION['sessUser_user_password'] != "" AND $_SESSION['sessUser_user_name'] != "") {


          $_SESSION['sessUser_user_id'] = intval($_SESSION['sessUser_user_id']);


          $_SESSION['sessUser_user_name'] = trim($_SESSION['sessUser_user_name']);


     $sql = "SELECT user_password FROM ".$user_prefix."_users WHERE user_id='" . $_SESSION['sessUser_user_id'] . "' AND username='" . $_SESSION['sessUser_user_name'] . "'";


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


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


     $pass = $row['user_password'];


          if($pass == $_SESSION['sessUser_user_password'] && $pass != "") {


               $_SESSION['sessUser_user_set'] = 1;


          return 1;


          }


          }


          return 0;


     } else {


     return 1;


     }


}

As you can see there is not much difference, but the fact is that I can safely set variable which propagates the rest of the script in a session saying that the user has been authenticated, the same could technically be accomplished in the first function by defining a constant and seeing whether or not it is defined the next time the function is called.

The way it is setup right now is very sloppy as in a given module you have several calls to is_user and several more to is_admin, currently it is a seperate check on the database each time instead of doing it initally and if it proceeds, assigning a variable saying it did so.

Since I am using the $_SESSION superglobal array the values cannot be misconstrued and made global via GET and POST because the global for them never exists in the code, also php inherently works with sessions being the last in the variable order and configuration depending means they have a higher priority and will therefore overwrite previously declared variables of the same global name in the $_GET, $_POST, $_ENV, and $_COOKIE methods.

On the other hand, if you declare with globals on

$_SESSION['raven_rules'] = "Yeah";

And then later in the script say
$raven_rules = "Maybe";

Your final product will be
$_SESSION['raven_rules'] = "Maybe";

The way to avoid this is to not use common variables so they will not be rewritten as is with the case above in the is_user function, if someone creates a module with those variable names I am going to be pissed! LOL!
Smile

Well I have gone on long enough, but hopefully this shed some light for some people. Also, the sessions don't have to be stored on the server as they are by default, you can define the session method and have php basically store them anywhere you would like (DB comes to mind) and PHP will be default handle all serializing and unserializing of the data. Sounds good to me. Smile

-Bill (Audioslaved)

P.S. About a week after I started this I stumbled on cpgnuke and read they have admin based sessions, they are on the right track, keep up the good work ladies and gents over there.

Posted: Wed Jun 09, 2004 8:17 am

Quote:

One of my main rebuttals to the author of the article is what is more secure than the actual server to store the variables, we saw how quickly someone was able to figure out the base64_decode method currently being deployed and use it at a great disadvantage to the community.

I am not biased one way or another. But, in fairness to the author of this particular article, that article is not related to nuke, at all, and he is not using Base_64 but md5() which is, for all intent and purposes, non reversable. As with all methodology, it can be sloppily coded, as is most of what FB's (nuke's) code is, or it can be correctly coded and secure. They both have merits Wink

Posted: Wed Jun 09, 2004 1:57 pm

I am sure that author knows a hell of alot more than I do so in all fairness to him I would have to agree. I guess i tend to fall on the sessions-fan side of the fence if it wasn't obvious of my post. Concerning my post, though the author was referring generally to php, I was talking more from a nuke perspective, if we are talking php-wise than both methods should be able to be deployed and maintained equally. As with what you said if coded correctly (which is far from the case in nuke's core about 50% of the time).

It may sound like I am unhappy with nuke, honestly, nuke has given me much and has been good to me, great people like you guys, humpa, the list goes on and on, have been there and kinda were like a mother hen, laughing at our stupidity with us, showing us the light etc, those type of people, regardless of how you feel about the product make you feel like you should give something back and do the good that was done to you for others. It is that sense of community and knowing the goodwill of others that still is a large reason I hang around, that and the passion of php. The bad mouthing of nuke's core, etc comes from me knowing deep down that nuke could be much more efficient, less bloaty, more secure and more functional straight out of the box. I guess that puts me in the sessions-based disgruntled employee category Laughing