Code fails to obtain "id" from table

MXIIA

http://pastebin.com/TnUyKZRD
The table, users, contains the columns "id" (an auto increment value), username, and password.
username is successfully identified and the user can log in fine, but their "id" is not stored as a session variable like username is, why is this?

Weedpacket

You can post code in these forums (see the FAQs for the markup tags to use). If the code is too large, only post what is relevant. If you don't know what is relevant, it's the bit that still shows the problem after everything else has been removed.

MXIIA

$encryptedPass = md5($passLogin);
$checkUserQuery = "SELECT * FROM users WHERE username='$userLogin' AND password='$encryptedPass'";
$checkUserQueryResults = mysql_query($checkUserQuery) or die(mysql_error());
if($login = mysql_fetch_assoc($checkUserQueryResults)){
 $_SESSION['username'] = $userLogin;
 $getuid = "SELECT id FROM users WHERE username='$userLogin'";
 $_SESSION['uid']= mysql_query($getuid) or die(mysql_error());
 $confirm = "Thank you, you are now logged in as $userLogin. <br />You may now continue to the <a href=\"index.php\">index</a>";
}else{
 $errors = "Sorry username/password do not match anything in our database please try again.";
}

That's the part where the problem resides. It does not go to the else portion, but merely sets $_SESSION['uid'] to 0.

Weedpacket

How are $passLogin and $userLogin set? Have you verified that there really is a matching record in the table for the query to find (see the Debugging 101 thread in the Echo Lounge (also linked in my signature if I haven't changed it since I posted this)); you want to see if the query you're sending to the database really is what you think it is - or if $userLogin or $passLogin/$encryptedPass are themselves wrong.

You shouldn't need the second query: you already have that information from the first (because you selected the entire row, not just the fields you needed). Also, note that $_SESSION['uid'] won't contain an ID, but a MySQL record set.

And thirdly, note that the MySQL extension has been deprecated in favour of the MySQLi or PDO extensions.

Okay; so I just looked at the pastebin code for a bit of relevant context; that business with looping over $_POST and setting $$key is a noticeable potential security hazard (see [man]security.globals[/man] for a history).

Also, you don't do any escaping of $userLogin (see http://www.xkcd.com/327); if you used bound variables (available through the newer interface extensions mentioned above) then the database driver could do the necessary escaping for you.

The other comments still apply.