From http://www.trap17.com/index.php/Php-Simple-Login-Tutorial_t7887.html
I have everything in place - registering a new user works fine with the information showing in the database. However, when I try logging in it always returns the error message (Sorry, could not log you in...). What I've done so far is increase the length of the password to 255 from what the tutorial specifies. I know it isn't the most secure login - just trying to get this to work first. :queasy:
Without seeing the code you've actually uploaded, there's not much to help you with. Or is it a direct cut-and-paste?
It's nearly the same, safe for the login details and such. Database successfully logs info from registration, it's just the login process that doesn't work as intended.
dbConfig.php http://pastebin.com/aiXTBK69
login.php http://pastebin.com/s8WJmVkB
register.php http://pastebin.com/ncSz4T6Y
members.php http://pastebin.com/2aFD8QUy
In the database how big is the field you're storing the password? I did have this happen to me when I moved from the OLD_PASSWORD function in MySQL to PASSWORD since the latter returns a string around 40+ characters whereas the original returns one only about the same length as the password. Hence, my stored password field on the DB was only about 16 chars and checking again never worked.
TheoGB;10945300 wrote:returns a string around 40+ characters whereas the original returns one only about the same length as the password.
Hence, my stored password field on the DB was only about 16 chars and checking again never worked.
THe tutorial link in first post says:
Name the table "dbUsers." It will need 4 fields:
Name Type Addition
id int(10) Primary Key, AUTO_INCREMENT
username varchar(16) Unique
password char(16)
email varchar(25)
So, TheoGB may be very right.
But we can not offer any real help
until we know about
- how the DB table actually is set up
- we can see how the login script is coded
Regards
It's set to 255 and each password is no more than 40 characters in length.
And you've checked the DB directly? What I mean is that you've either used a view to the DB like phpMyAdmin or the command line to check it works:
SELECT * FROM `dbUsers` WHERE `username`='{your username}' AND `password`=PASSWORD('{your password}') LIMIT 1
Run that directly with the appropriate values and make sure you get a response because if that fails then there must be a problem with the size of the field for password on the database. As halojoy points out, your tutorial specified 16 chars and when you talked about the field being 255 chars before it sounds like you were referring to the HTML input fields not the field on the database.
Oh wait, you definitely re-registered after increasing the password field to 255 if you did that? I mean, if you'd already registered then increase the field size the password you entered will still be truncated and won't work.
With this sort of thing you have to make sure the DB is returning the values you expect from the SELECT statements you're sending through.
All passwords in the database were made after the 255 character change. Running that query on the command line in phpMyAdmin returned the result for the user/pass I specified.
Does it matter whether I use icexb_dbUsers or dbUsers when referencing them in the php files?
arghb;10945308 wrote:Does it matter whether I use icexb_dbUsers or dbUsers when referencing them in the php files?
I would have thought so but I don't entirely get what you mean. Is your table called icexb_dbUsers or dbUsers? As long as your connection in the dbConfig.php file is to the correct database then you need to reference the correct table name in that database. You don't need to prefix it with a database name or anything.
Assuming, then, that your login.php matches the code they've given you I'd make the following amendments:
<?php
session_start();
// dBase file
include "dbConfig.php";
if ($_GET["op"] == "login")
{
if (!$_POST["username"] || !$_POST["password"])
{
die("You need to provide a username and password.");
}
// Create query
$q = "SELECT * FROM `dbUsers` "
."WHERE `username`='".$_POST["username"]."' "
."AND `password`=PASSWORD('".$_POST["password"]."') "
."LIMIT 1";
/*** Amendment 1 */
echo "Query: ".$q."<br/>";
/*****/
// Run query
$r = mysql_query($q);
/*** Amendment 2 */
echo "<b>MySQL Result </b><br/>";
print_r($r);
echo "<b>End MySQL Result</b><br/>";
/*****/
if ( $obj = @mysql_fetch_object($r) )
{
/*** Amendment 3 */
echo "Login success <br/>";
/*****/
// Login good, create session variables
$_SESSION["valid_id"] = $obj->id;
$_SESSION["valid_user"] = $_POST["username"];
$_SESSION["valid_time"] = time();
// Redirect to member page
Header("Location: members.php");
}
else
{
// Login not successful
die("Sorry, could not log you in. Wrong login information.");
}
}
else
{
//If all went right the Web form appears and users can log in
echo "<form action=\"?op=login\" method=\"POST\">";
echo "Username: <input name=\"username\" size=\"15\"><br />";
echo "Password: <input type=\"password\" name=\"password\" size=\"8\"><br />";
echo "<input type=\"submit\" value=\"Login\">";
echo "</form>";
}
?>
You haven't said how it fails so I wasn't sure if you're getting the 'die("Sorry...' bit or it's just not working somehow, hence the 3rd amendment.
If you run that Check the query looks right and then also check the result of the query. That Print_r() method will show everything on one line but if you CTRL+U to view the page source it'll be much easier to read.
I believe I was mistakenly referencing the database name and not the table name when the query called for it (see original post for php files). Now the issue is no members.php being displayed after login success.
Warning: Cannot modify header information - headers already sent by (output started at /home/icexb/public_html/login.php:24) in /home/icexb/public_html/login.php on line 32
Have you left in the code amendments I gave you? Google implies that this error comes about when you have any echo statements running prior to the Header() statement.
Personally using Header() this way is only something I've seen in the last few days on this forum so I'm not familiar with it. I use http://smarty.php.net as my templating system to output data.
Sanitize the userinput. If the code above is what your are doing, then you have "sql-inject me" written all over it. Logins warrant some security condsiderations...
(the above link shows some old-school measures matching your old-school mysql approach. have a look at mysqli and prepared statements for new-school 
)
Ammendment 4: Never use @ to suppress errors.
Ammendment 5: see signature
arghb;10945308 wrote:All passwords in the database were made after the 255 character change. Running that query on the command line in phpMyAdmin returned the result for the user/pass I specified.
Does it matter whether I use icexb_dbUsers or dbUsers when referencing them in the php files?
Which table is the data in? Is it in icexb_dbUsers or is it in dbUsers?
arghb;10945312 wrote:I believe I was mistakenly referencing the database name and not the table name when the query called for it (see original post for php files). Now the issue is no members.php being displayed after login success.
Warning: Cannot modify header information - headers already sent by (output started at /home/icexb/public_html/login.php:24) in /home/icexb/public_html/login.php on line 32
Pikachu2000;10945350 wrote:Which table is the data in? Is it in icexb_dbUsers or is it in dbUsers?
Original issue is solved now. See above for the current one.
There are four echo()'s before header(). Nothing can be sent to the browser before header(), or it will tell you that "headers have already been sent".
Login success with members.php! 
Bjom;10945331 wrote:Sanitize the userinput. If the code above is what your are doing, then you have "sql-inject me" written all over it. Logins warrant some security condsiderations...
(the above link shows some old-school measures matching your old-school mysql approach. have a look at mysqli and prepared statements for new-school
Ammendment 4: Never use @ to suppress errors.
Ammendment 5: see signature
"mysql_real_escape_string" has now been added to POST. Hopefully that takes care of injection problems. Can mysqli be taken advantage of on 4.1.22?
In regards to using @, it is a commonly used method for hiding crucial information that you wouldn't normally want any visitor to see, no?
The error returned when using die() seemed real straightforward to the end user. With E_USER_ERROR it is now "Fatal error: You must provide a username and password. in /home/icexb/public_html/login.php on line 10" That seems like more information than needed, and not in a particularly elegant way. 
Using die() is a very poor way of handling an error. It's the web site equivalent of abruptly hanging up on a phone call if the caller makes a mistake. Or a storeowner frog-marching a customer out of the door and locking it on them if their credit card is declined.
die() and error messages are for the programmer's benefit, not the end user's. That's why recommended best practice is to turn error message display off and log them instead. And provide the user with a proper page explaining that there is a problem and if they made a mistake providing them with an opportunity to correct it.
arghb;10945445 wrote:Login success with members.php!
"mysql_real_escape_string" has now been added to POST. Hopefully that takes care of injection problems. Can mysqli be taken advantage of on 4.1.22?
In regards to using @, it is a commonly used method for hiding crucial information that you wouldn't normally want any visitor to see, no?
The error returned when using die() seemed real straightforward to the end user. With E_USER_ERROR it is now "Fatal error: You must provide a username and password. in /home/icexb/public_html/login.php on line 10" That seems like more information than needed, and not in a particularly elegant way.
The better way to handle error display and log errors (you do log errors, right? ) would be along the lines of the code below. It's a rather basic example, but it should give you some ideas on how you could use it. Rather than just terminating the script with a white screen, it gives the user a chance to do something to correct it and continue. EDIT: Don't take this to mean I think you should log all errors, but you should log certain ones.
<?php
$errors = array();
if( isset($_POST['s1'])) {
if(strlen($_POST['name']) < 2) {
trigger_error( "User submitted name that was too short." ); // log the error
$errors[] = "Name must be more than 2 characters"; // add message to array for display later
}
if(strlen($_POST['pw']) < 6 || !is_numeric($_POST['pw'])) {
trigger_error( "User submitted improper password." );
$errors[] = "Password must be a number of at least 6 digits";
}
if(!empty($errors)) { // if there are errors, list them for the user to see.
echo( "The following errors occurred:<br>" );
foreach( $errors as $key => $val ) {
echo( $val . "<br>" );
}
}
}
?>
<form action="<?php echo( $_SERVER['PHP_SELF'] ); ?>" method="POST">
<input type="text" name="name"><br>
<input type="password" name="pw"><br>
<input type="submit" name="s1" value="Send Form">
</form>
Well, I've played around with CodeIgniter and I have to say it seems a bit easier to deal with than this. I have the same login prompt but with form validation and more security to boot. This probably spells the end of the coding experiment. A generous thank you to everyone that chimed in!