Forum Moderators: coopster

Message Too Old, No Replies

doesn't work any more- what happend?

         

Gilead

8:39 pm on Nov 22, 2011 (gmt 0)

10+ Year Member



Just when I thought I was about finished. This script used to work, I don't know what happened except I changed to a session variable. This will enable admins to make new admins.

form:
<?php
session_start();
if (!$_SESSION) {
header("location: loginpage.php");
}
?>
..
<?php
// using md5 random
// $length = 8 can be change, its length of password character
function randompassword($length)
{
return substr(md5(rand().rand()), 0, $length);
}

$password= randompassword($length = 8);
?>

<br />
<br />
<form method="POST" action="addadmin.php" onsubmit="return Form1_Validator(this)" name="theForm" language="JavaScript">
First Name:<input type="text" name="firstname" value=""><br />
Last Name:<input type="text" name="lastname" value=""><br />
Login Name:<input type="text" name="username" value=""><br />
Password:<input type="text" name="password" value=" <?php echo $password ?>"><br />
Access Level:<select size=1 name="accesslevel">
<option selected value="Admin">Admin</option>
<option value="SuperUser">SuperUser</option>
</select><br />
Email:<input type="text" name="email" value=""><br />
<input type="submit" name="submit" value="Add Admin"><input type="reset">
</form>

addpage:
<?php
session_start();
if (!$_SESSION) {
header("location: loginpage.php");
}
//prevents caching
header("Expires: Fri, 01 Jan 1988 00:00:00 GMT");
header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT");
header("Cache-Control: post-check=0, pre-check=0",false);
session_cache_limiter();


?>

<?php
include ('config.php');
$table_name ="authorize";

//make query to database
$sql ="SELECT * FROM $table_name WHERE username= '$_SESSION[username]'";
$result = @mysql_query($sql) or die(mysql_error());

$firstname=mysql_real_escape_string((addcslashes($_POST[firstname], "%_")));
$lastname=mysql_real_escape_string((addcslashes($_POST[lastname], "%_")));
$login=mysql_real_escape_string((addcslashes($_POST[username], "%_")));
$password=mysql_real_escape_string((addcslashes($_POST[password], "%_")));
$access_level=mysql_real_escape_string((addcslashes($_POST[accesslevel], "%_")));
$email=mysql_real_escape_string((addcslashes($_POST[email], "%_")));

echo $result;
echo '<br />';
echo $firstname;
echo '<br />';
echo $lastname;
echo '<br />';
echo $login;
echo '<br />';
echo $password;
echo '<br />';
echo $access_level;
echo '<br />';
echo $email;
//get the number of rows in the result set
$num = mysql_num_rows($result);
echo 'number of rows';
echo $num;
if ($num != 0){

echo "<P>We apologize, that username already exists.</P>";
echo "<P><a href=\"#\" onClick=\"history.go(-1)\">Try Another Username.</a></p>";
echo "$_POST[username]";
exit;
//no matter what I do, it ends up saying username exists. I look in cpanel to make sure, it is not there. What am I missing?

}else{

//or add it to the database
$sql_add = "INSERT INTO $table_name (firstname, lastname, username, password, access_level, email) VALUES ('$firstname', '$lastname', '$login',
'$password', '$access_level', '$email');";

$result = @mysql_query($sql_add) or die(mysql_error());
echo 'Admin Added';

}
?>
<br /><a href="addnewadmin.php">Add another?</a><br/> <form action="email_user.php" method="get"><input type="submit" value="SEND USER EMAIL"/>
<input type=hidden name=login value="<?php echo $login ?>" />
<input type=hidden name=password value="<?php echo $password ?>" />
<input type=hidden name=email value="<?php echo $email ?>" />
</form><br />
<a href="index.php">Admin Home</a> <a href="viewmembers.php">View/Modify/Delete User</a>
</body>
</html>
Thanks!
I take out the session variable and it works just fine! Why?

londrum

8:55 pm on Nov 22, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



this is probably too easy, but shouldn't this line
$sql ="SELECT * FROM $table_name WHERE username= '$_SESSION[username]'";


be

$sql ="SELECT * FROM $table_name WHERE username= '".$_SESSION['username']."'";


(you need apostrophes around the 'username' bit)

Gilead

9:10 pm on Nov 22, 2011 (gmt 0)

10+ Year Member



For some crazy reason that worked. I don't have those separators in other calls using $_SESSION, but one more piece of the puzzle. :-)
Thanks!

penders

9:41 pm on Nov 22, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



(you need apostrophes around the 'username' bit)


Hhhmmm... I don't think this is it?! Both these lines result in the same output. Using 'simple syntax' in variable parsing you should not enclose the array index in quotes. Yes, a little confusing, which is why I would always use 'complex' (curly brace) syntax, or use string concatenation as in the 2nd line.

But what do I know - this seems to have fixed it!? But are you sure nothing else has changed - may be the session?

eelixduppy

10:02 pm on Nov 22, 2011 (gmt 0)



Typically when using an array in a string like this, it should be handled as londrum has shown, or the following (as penders hinted) by surrounding with brackets:

$sql = "SELECT * FROM $table_name WHERE username= '{$_SESSION['username']}'";


But to be honest, you should be using a prepared statement here which will not only solve this issue, but it will be more secure:

[php.net...]

Gilead

12:07 am on Nov 23, 2011 (gmt 0)

10+ Year Member



a prepared statement? Can you elaborate please?

g1smd

12:31 am on Nov 23, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



See the link in the post above.

enigma1

9:34 am on Nov 24, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Both these lines result in the same output.


They shouldn't.
The first line:
$_SESSION[username]
which is wrong in this case expects username to be a definition. It should show a warning subject to the PHP error level.
The second
$_SESSION['username']
Will return the username indexed value from the session array.

As of the security I don't know how much security a prepare will add at this point if the $_SESSION['username'] is already populated. You should apply the filter before you assign it to the session var.

PS: and the same problem goes for the $_POST array

penders

10:39 am on Nov 24, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



They shouldn't.
The first line:
$_SESSION[username]
which is wrong in this case expects username to be a definition. It should show a warning subject to the PHP error level.


They should, and they do.
$_SESSION[username]
is not used by itself in this instance (in which username would indeed be expected to be a defined constant), but it is used as part of a double-quoted string and is therefore parsed for variables (constants are ignored during variable parsing). This is the simple syntax for array elements in variable parsing [uk3.php.net] - but, as mentioned, it is confusing and is rarely (should not be) used. In favour of string concatenation, or complex syntax.

enigma1

11:34 am on Nov 24, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Yes I understand, Now the double quotes surround the sql statement. But then you have single quotes that surround the session element. You said you get the same result. How can you get the same result?

For example:

$fruits = array(
'banana' => 18,
);
echo "A banana is $fruits[banana].";
echo "A banana is '$fruits[banana]'.";

You get 2 different results don't you?
At least on the php version I try here I don't get the same result.

PS: Ok I see when he breaks up the sql string the quotes are added and so the result should be the same on both

penders

12:19 pm on Nov 24, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Yes, in your example you get 2 different results, but the example posted above is different to your example... the single quotes that surround the session element are always present:

$sql ="SELECT * FROM $table_name WHERE username= '$_SESSION[username]'";


$sql ="SELECT * FROM $table_name WHERE username= '".$_SESSION['username']."'";


$sql = "SELECT * FROM $table_name WHERE username= '{$_SESSION['username']}'";


All 3 result in the same output. The first one is how it appears in the original code.

eelixduppy

3:48 pm on Nov 24, 2011 (gmt 0)




As of the security I don't know how much security a prepare will add at this point if the $_SESSION['username'] is already populated.


You shouldn't always assume session variables contain what you expect, especially in a shared hosting environment. And I would say it is not good to escape a string long before it is going to be used in a query due to other factors, as well.

enigma1

10:08 am on Nov 25, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



If you haven't set the session path to point to your domain in a shared environment or store sessions in another medium like your database, you're asking for trouble. What you assign to session vars should be filtered during the assignment. And due to the nature and limits of sessions you use verified identifiers or pointers to database entries rather than storing various content.

In the above code sample I cannot see where the session username is assigned. I would expect it to be an entry from the database and although not a great implementation, it was previously filtered.

londrum

1:57 pm on Nov 25, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



it might have something to do with the fact that you're not allowed to include a space in a variable name. and we're checking for $_SESSION[username] here -- which presumably might contain a space.
if you don't have the apostrophes then that's what you're doing -- checking for a variable name.
the script will convert the spaces to an underscore instead. so when it checks the database, of course it can't find it, and returns zero rows.

but you are allowed to use space in an array index. and if you put the apostrophes around it then that's what you're doing -- checking for an array index. so that will pass through okay.

[ps. i might be talking a load of rubbish, but that's how i understand it. i always include the apostrophes anyway, just to avoid the hassle of having to remember all these complicated rules.]