tags:

views:

48

answers:

2

I'm attempting to use multiple ANDs in this query below, and it messes up the password every time when I attempt to use my login feature. code below.

// this is my problem, right here
    $result = mysql_query("SELECT username, password, FirstName FROM members 
                            WHERE username='$myusername' 
                              AND password='$mypassword' 
                              AND  FirstName = '$firstname'");

// Mysql_num_row is counting table row
$count=mysql_num_rows($result);
// If result matched $myusername and $mypassword, table row must be 1 row


if($count==1){
// Register $myusername, $mypassword and redirect to file "login_success.php"
session_start();
$_SESSION['myusername'] = $myusername;
$_SESSION['mypassword'] = $mypassword;
$_SESSION['firstname'] = $firstname;

EDIT:

SQL Query:

Table Name: members

username | password | FirstName | LastName 
johndoe    deers       John        Doe

PHPMyAdmin tells me it returned zero rows when I run it there.

+3  A: 

A) Don't store the password in memory at all

B) Hash the password

C) There's no reason to filter where FirstName = anything if you're already filtering by username and password. Are you asking the user for their username, password and FIRST NAME when they log in? Where are you getting that variable from? Are usernames not unique or something?

andyortlieb
A) Yes I knowB) I will be doing this, no worriesC) No, but I want to access the FirstName and all of the other data in that row after they login. That's my main question. Thanks for the help so far!
SkyWookie
Your are already getting everything in the row in the SELECT query. The question still remains: why filter on FirstName?
TNi
You can still select FirstName without filtering by FirstName.
andyortlieb
Well I just don't know how to set FirstName of the user to a $variable. I want to print it out and such!
SkyWookie
I hope I'm mistaken here... but do you think that your WHERE clause is assigning those variables? Because it isn't. You have to fetch the row and iterate over the result and assign those variables.
andyortlieb
No, I didn't include it, but $myusername and $mypassword are declared earlier, they are set to $_POST['myusername'] and $_POST['mypassword'] respectively.
SkyWookie
So did you stop filtering by FirstName then? Without setting that variable before your query, you're asking the database to give you a record where username='x', password='y' and FirstName=''. But understand it's impossible to set a value to $firstname before your query because that information (FirstName) will not be available until after your query.
andyortlieb
A: 

If I understand correctly the problem, you should check that you type the case of the username, password and FirstName correctly (meaning the values which you check in the database).

If you want to make it case insensitive you should use LIKE.

Also if this comment is right

// If result matched $myusername and $mypassword, table row must be 1 row

This means that you shouldn't even check for FirstName in first place?

Also if you can give sample data, this would help a lot!

bisko
I've never seen any remotely modern DBMS compare text case-sensitively in a VARCHAR or CHAR column. If yours does, it's broken and should be replaced with something from the past 20 years.
cHao
@cHao: I have, Oracle. It depends on the collation - some DB's set per table (and possibly column?), otherwise database wide.
OMG Ponies
@OMG Ponies: And...this is the point where i say "Well then, Oracle needs to be taken out back and shot." Or maybe just the DBAs do.
cHao
@cHao: You missed the part about the collation being key, not the vendor.
OMG Ponies
For reference, `SELECT 'aBc' = 'Abc'` returns 1.
cHao
@OMG Ponies: In every language that has a concept of upper vs lower case, the collation should consider 'A' and 'a' to be the same letter in equality comparisons. If it doesn't, that's the DBA's fault, if not the DBMS's.
cHao
@cHao: That is your belief, not fact - MySQL, the default collations (latin1 and latin1_swedish_ci) are case insensitive: http://dev.mysql.com/doc/refman/5.1/en/case-sensitivity.html These are not "languages", per se.
OMG Ponies
@OMG Ponies: OK, perhaps i've been spoiled by MySQL and its reasonable defaults. (I never thought i'd say "spoiled by MySQL" in my lifetime, but hey.) Either way, and getting back to MySQL, that's the *default*. Someone would have to change the collation to something case-sensitive in order for case to matter, which i pretty much guarantee isn't the case here, or the OP would be knowledgeable enough to be well aware of it
cHao