06-22-2005, 08:29 PM
Can anyone spot an error that would keep this Ashok Appu script from working? All mysql table names are correctly matched. Error: User does not exist!
or die("Database connection failed ! <br>");
or die("Database could not be selected");
$query = "INSERT INTO login VALUES('". $customerid ."', '". md5($password) . "')";
//$result = mysql_query($query);
die(" Query could not be executed.<br>");
<table width="330" border="0" align="center" cellpadding="5" cellspacing="2">
<td colspan="2" bgcolor="#dddddd">
<div align="center"><b>New password entered for
<?php echo $customerid;?>
<?php echo $customerid; ?>
<?php echo $password; ?>
<td colspan="2"><center>Try your new password in the <a href="login.htm">login page</a></center></td>
06-22-2005, 10:13 PM
I can enter the password manually into the mysql data base but the code on the page is not doing it ... need help, please....
06-22-2005, 10:24 PM
Is that all the code? $customerid and $password aren't even declared in there, where are they coming from?
06-22-2005, 10:38 PM
This is a file that is processing a form and returning a table vertifying the information. The password comes up as verified but when I try to log in with it I get the message that "not a user". I can enter the password manually in PhyMyadmin but the PHP code doesn't work.
06-22-2005, 10:41 PM
Is it possible that you have register_globals turned off, meaning that you can't access $customerid and $password directly? Try changing your database query to:
$query = "INSERT INTO login VALUES('". $_POST['customerid'] ."', '". md5($_POST['password']) . "')";
and see if that works. It's a better way to work with globals in general, anyway, since it's more secure if you know exactly where your variables are coming from.
Also, do the password and customerid show up properly in the table?
06-22-2005, 10:45 PM
Register globals are on. I am working from a book (Ashok Appu) and he writes them this way.
06-22-2005, 10:47 PM
And, yes, the password and id show up on the table...the password is encrypted
06-23-2005, 01:15 AM
1. Always, always always! Script as if your register globals are off. Secure any uninitialized and script run variables which register globals creates, and eliminate them immediatly. With your database entries the way they are, with no previous initialization and no securing with htmlentities/addslashes/mysql_real_escape_strings if a user knows of your database structure, it would take minutes to cripple your database integrity.
With that out of the way.
It appears that the user is never inserted into the database, as your query has been commented out. This could be what you are looking for. If not, perhaps it is that your $customerid is not turning up a number. Assuming this is via get or post, you can confirm its existance using $_REQUEST['customerid'] instead to make sure it is indeed there. But I believe its the insertion you are looking for. As well, you don't need to create a resource for the insertion, just use mysql_query($query) and it will execute. Don't bother using $result = mysql_query($query); off hand, I don't believe that will work as now you have declared it as a resource instead of as an execution. Don't quote me on that though, its possible that it will work just fine either way.
06-23-2005, 01:36 AM
Hurrah! you hit it on the head. I just did not notice the commented out line. Guess I have been staring at the code for too long.
I am new to PHP and trying to learn from books. I know about the global registers thing but go along with whatever author I am working with as I learn.
I don't know why this author chooses to do it this way but.....whatever.
I am so glad to get this problem solved. Thank you so very much for taking the time to answer my questions... Betty
06-23-2005, 01:51 AM
No problem betty, glad it works. The original author was probably creating while it was 'assumed' register globals was an included use of php, and not an additional feature.
Here is my suggestion then for use of register globals. First, most servers will handle scripts as register globals being on. So that is a plus. Unfortunatly, register_globals are bad. They are very simple to get around though.
All registered variables come from somewhere in the first place - you just need to know where they are comming from.
$_GET = within your url querystring : page.php?do=this&who=me // 'Who' and 'do' are your variables.
$_POST = from form data
$_COOKIE = from cookies
$_SERVER = server contained variables
$_SESSION = session variables. A section all of its own...
$_REQUEST = usuall composed of $_GET and $_POST data. Can be easily altered though for your purposes.
$_FILES = uploaded files.
$* = any defined variable within your $GLOBALS.
This is a list of your supergloblas, with the exception of the final entry. The final entry is any variable created from using register_globals as on.
Now, I know your fairly new with php and I don't want to seem like a major stickler, but the importance of using superglobals is something I cannot stress enough. And its best to learn while you are new.
Ok, so instead of creating a variable that has been registered, you would access it using its superglobal array:
// $customerid is defined within a url querystring: index.php?customerid=1
$customerid = $_GET['customerid'];
// $customerid is defined within a form posting: <input type="*" name="customerid" />
$customerid = $_POST['customerid'];
// Can be from either a url querystring or post data:
$customerid = $_REQUEST['customerid'];
/* Note, I've seen some servers with $_REQUEST unset or merged incorrectly.
I solve this myself by creating request:*/
$_REQUEST = array_merge($_GET, $_POST); // for instance. I give priority to my $_POST data.
And thats all there is to using superglobals instead of registerglobals. The benifit is that its now a portable script and can be used on different servers.
One exception will come to this as well, and its the use of a scope. Functions do not see the scope beyond themselves, and any set variables need to be defined within them. Its been years since I used register_globals, but I would assume with them on, globalization of standard variables would not be nessessary for a function as all globals and superglobals are automatically available. Of course, this has an exception as well, and it involves your version of php. If its pretty old, superglobals are not available, however the depreciated arrays of $HTTP_*_VARS are available.
Whew. I'm sure I've bored you to death by now ;)
PM me if your interested in learning more about superglobals and how they are used.
Also, thought I'd mention that more and more hosts are opting for the default configuration of register_globals = off. Another reason to use them!