home—lects—exams—hws
D2L—breeze (snow day)

lect10-ch12-mysql
MySQL
chapter 12

From PHP Visual Quickstart Guide by Larry Ullman.
Originally base on notes by Jack Davis (jcdavis@radford.edu)

This chapter will focus on accessing MySql database tables from PHP programs. A database is a collection of tables (rows & columns) that store information. Databases are created, updated, and read using SQL (Structured Query Language). There are surprisingly few commands in SQL. SQL was designed to be written a lot like the English language, which makes it very user friendly; but it does take some thought to create more elaborate SQL statements with only the handful of available terms.

The process is quite simple: PHP is used to send SQL statements to the database application, where they are executed. The result of the execution - the creation of a table, the insertion of a record, the retrieval of some records, or even an error - is then returned by the database to the PHP script.

Setting up a MySQL database on your RU account:
- Go to php.radford.edu > MySQL hosting page.
- Follow the instructions for 'Request/create a MySQL database'.
- Once you have set up your MySQL account, you can write php programs that save/retrieve info from your database.
- If you want to interact with your database via MySQL Admin Tool, you can follow links to php.radford.edu > MySQL hosting page > RU Mysql Admin Tool.
(Note that if you want to connect to the dept Oracle server you used in itec340, instead of a MySQL database.) here is an example php program which does so.)
PHP's mysqli_query function is the most-used command. It sends an SQL command to MySQL, and returns the result from the DB:
$result = mysqli_query(connection, SQL statement);
However, before we do this, we need to get a connection to the database: create the connection (with username and password), and then select which schema you want to use (in this class, you'll use the one personal schema that RU gives you).

RU's connection to a MySQL database --

           $conn = mysqli_connect(hostname, username, password, schemaToUse );
           // @param hostname  For php.radford.edu, use 'localhost'
           // @param username  the database account, which is the same as your RU userid
           // @param password  the *database* password.
           // @param schemaToUse your RU userid (again!) -- it's a DB account *and* a DB-schema.

Eventually, when you are done working with the database, be sure to close the connection!
mysqli_close(connection);
Although the database and/or php will eventually reclaim old, unused database connections, it's always better to do so yourself.
(Inadvertent denial-of-resource attack: students create connections w/o closing them; after 10 students each running their program 10 times, the DB server gets clogged up, and new connections start taking a long time!)

    $connect = mysqli_connect(...) || die('connect failed.');
    echo "The connection ", ($connect ? "" : "NOT "), "established.\n";

    // If I use '... = connect || die' like this, then the following fails(!):
    $info = mysqli_query( $connect, "SELECT * FROM Students" );

Note that the green and red text don't mingle: The boolean operator || always returns a boolean (not merely boolean-ish), which not the same as whatever the result of mysqli_connect was. So when we try mysqli_querythe first argument is true, and not a connection-resource.
(Note that you'll see this construct because an older, deprecated function mysql_query had a convenient feature that the connection was optional, and defaulted to the most-recently-opened-connection. Nowadays, the preferred solution is to use a connection-object, and call it's method query.)

Using mysqli_* as opposted to odbc_*:
1. Alas, some important function have no generic odbc counterpart: e.g. mysqli_real_escape_string.
2. There are some minor differences: e.g. there is no odbc_select_db because that functionality is subsumed by odbc_connect's more general first argument (which is a connection-string including many details).
3. odbc_connect is not installed on php.radford.edu (I'm not sure why -- isn't it a provided, standard php function?)
4. To connect to an oracle database (instead of mysql), the function names are prefixed with “oci”.
  See: db-oracle-connect.php
  (be sure to close the connection after making it)
Security note: Your php code contains your database password. Be extra sure your .php file is not public-readable (that is, readable by any other user logged in to rucs)!
Common strategy: Put your 'connect' statements into a separate, included file. (a) This helps because you'll be re-using this code many times; (b) even if you show_source of the main file, your password is in the other file.

One kludgy way of doing this is to have the include-file store the connection it creates in a special variable — perhaps “theConnection” — and then all your files using the database will all have to remember ot use that one variable (and not to use that variable themselves).

Better, I suggest having that file define a function named something like DB_connect_as_ibarland(), and it returns the database connection. That lets each file use whatever variable it wants to store the result (though yes, each file still needs to not trample on the name of that function.)

It's also possible to simply have the external file define a couple variables (like $dbUserName = … and $dbUserPasswd = …), and keep that file non-public.
Common SQL Commands
- SELECT - retrieves records from a table
- INSERT - adds a record to the table
- UPDATE - updates records in a table
- DELETE - deletes individual records from a table
- CREATE - creates a table
- DROP - deletes a table

INSERT -


           $var = 'Amy Johnson';
           $qu = "INSERT INTO $tablename (numItems,product,custName) VALUES (17,'abc','$var')";
           $allRows = mysqli_query($connect, $qu);

SELECT -

           $qu = "SELECT * FROM $tablename WHERE (product = 'abc')";

           $allRows = mysqli_query($connect, $qu);

After execution of this query, $allRows will presumably be a table — “bunch” of rows (PHP/Mysql calls it a “resource”). You'll then want to process each row, one-by-one:

           while ($oneRow = mysqli_fetch_array($allRows)) {  # Note use of `=` for assignment *and* return value
             echo $oneRow['custName'], " bought ", $oneRow['product'];
             // We could also use $oneRow[0], $oneRow[1], $oneRow[2] but it's preferred to use column-name when possible.
           }

You might want to check for an error — something like the database complaining that it wasn't a valid SQL statement, or that the database connection had been lost (after being previously created).

          $allRows = mysqli_query($connect, $qry);         // A table object (possibly w/ 0 rows); NULL on query-failure.
          if (!$allRows)  echo "query failed -- lost connection?";

Note that getting back a table with 0 rows is not an error!

If you know your query should always return 1 row, so you won't have a loop. Other times, you just want to know whether the query returned 0 or 1 rows (e.g., you queried something like studentID='1234' and libraryFine = 0). In that case, you might have:

          $allRows = mysqli_query($connect, $qry);         // A table object (possibly w/ 0 rows); NULL on query-failure.
          if (!$allRows)  echo "query failed -- lost connection?";

          $topRow = mysqli_fetch_array($allRows);

          if (!$topRow)  {
              echo "table had 0 rows"
              }
          else {
              echo "table had (at least) 1 row".
              }

Even if your query should return 0 or 1 rows, because of SQL injection (below) be wary about assuming "there was at least 1 row" with "there was exactly 1 row"; you might want to check:

          $allRows = mysqli_query($connect, $qry);         // A table object (possibly w/ 0 rows); NULL on query-failure.
          if (!$allRows)  echo "query failed -- lost connection?";

          $numRows = mysqli_num_rows($allRows);
          if ($numRows == 0) {
              echo "table had 0 rows"
              }
          else if ($numRows == 1) {
              echo "table had exactly 1 row".
              $topRow = mysqli_fetch_array($allRows);
              }
          else {
              echo <<<END_OF_MSG
              Table had more than 1 row.
              If I think my query shouldn't every yield > 1 row,
                then I might just have built my query incorrectly.

              OR, if I incorporated user-input when building my query,
              then my code may have just succumbed to a SQL-injection attack! 
              Read below, about using  on user-input,
              before splicing it into a SQL query.
              END_OF_MSG;
              }

mysqli_free_result( $allRows );

DELETE -
$qu = "DELETE FROM $tablename WHERE (field1 = 'abc')";
To see if a DELETE query worked, you can use the mysqli_affected_rows($connect)
this function returns the number of rows affected by an INSERT, DELETE, or UPDATE
UPDATE -
$qu = "UPDATE $tablename SET $field_name1 = 'abc' , $field_name2 = '$newval' WHERE ($field_name1 = '$var')"; $allRows = mysqli_query($connect, $qu);
Remember that usually, when using SQL's UPDATE and DELETE, we'll provide a WHERE clause involving the table's primary key, so that the update/delete targets just one row. (You can certainly do mass updates/deletes, but they're not as common.)
Example: lect10-ch12-mysqli-example.php.
Also, you can look at a version that uses connection-objects: instead of someMethod($someObj, $otherArgs …) you just ¹ write $someObj->someMethod($otherArgs …).

Constraints in mysql

If you want to add or drop FK constraints in mysql: When creating a table, you can specify some Foreign Key (FK) constraints (apparently: from one column to a primary-key column). If you want to have a composite FK involving two columns, or a FK to a non-PK column, you can't just click the myphpAdmin GUI; you'll have to issue the SQL commands. (Note that myphpAdmin includes a pane for typing raw SQL commands, if you don't want to include it in php program.)

-- To create a FK 
alter table Goo
add constraint Goo_ij_FK 
Foreign key Goo(i,j)
references Foo(m,n)

-- To delete:
alter table Goo
drop foreign key Goo_FK
  -- it seems odd to me, to say 'drop foreign key ...' rather than 'drop constraint ...'.

If you're having difficulty, you can also see this thread (I think: You have to use the engine InnoDB instead of the default MyISAM, and you may have to declare an index on both the column in the parent table, and the child table.)

Q: What is the problem with the following?:
1. $theItem = "coffee"; $theQuery = "SELECT * FROM Inventory WHERE (product = $theItem)"; $results = mysqli_query($connect, $theQuery );
  A1: in the string “SELECT * FROM Inventory WHERE (product = coffee)”, there are no SQL-quotes around the value “coffee”, which should presumably be a string-literal: “SELECT * FROM Inventory WHERE (product = 'coffee')”.
  This is a very common sort of error, and it can be detected/debugged by printing $theQuery, and running that query on the database by hand to check whether it really is legal SQL.
2. What if we change the first line to $theItem = htmlspecialchars($_POST['itemSelection']);? (Presuming we came from a form with a text-entry named itemSelection).
  A2: If somebody had entered the four-character string “M&Ms” we wouldn't want want to look in our database for something including the characters “amp”. (Our database should include the correct name of the product; we'll turn “M&Ms” into “M&Ms” only when we display that on a web page — but not in emails, internal reports, etc..)
3. What if we change the first line to $theItem = $_POST['itemSelection'];?
  A3: What if the user had entered a name that contains a single-quote? See below, re SQL Injection!

SQL Injection Attacks

Here is some typical code which validates a user, by looking up their name/password in a table we have previously created:

          $user = $_POST['username'];
          $passwd = $_POST['password'];
          $qry = "SELECT * 
                  FROM MyPasswords
                  WHERE name='$user' and pass='$passwd'";  // DANGER!  SQL injection possible.
          $result = mysqli_query($connect,$qry);           // A table object (possibly w/ 0 rows); NULL on query-failure.
          if (mysqli_fetch_assoc($result)) {    // Safer: `if (mysqli_num_rows($result) == 1) ...`
              // login successful -- we found that name/password in our db!
              }

If the user had typed in fred and xyz123, then sure enough the database query would be (as we expect)

          $qry = "SELECT * 
                  FROM MyPasswords
                  WHERE name='fred' and pass='xyz123'";

BUT: What if the user had typed in a single-quote in their input? Suppose they typed O'Toole — why will the query fail?
WORSE: Can the user type in something so that the SELECT statment always returns a result?
Alas, yes! Something like: ' or 2+2=4 leads to a query that always turns true. (Though we still need to deal the final-single-quote that the query is making:)

          $qry = "SELECT * 
                  FROM MyPasswords
                  WHERE name='fred' and pass='' or 'security' != 'good'";

Warning: Always call mysqli_real_escape_string on any user-provided string that is getting integrated into a database query.

Now you may feel that if you've already done other validation on the data and know it doesn't contain any single-quotes or other characters SQL might mis-interpret, then you're safe. That's true. However, you should still call mysqli_real_escape_string! The primary reason is changing specs: When Peter O'Toole calls your boss to complain that your web form doesn't allow apostrophes, and your boss orders some schmo new programmer to change the validation-code for the form to allow apostrophes, it's easy to to miss that you have suddenly opened your site to SQL injection attacks!

(Another reason to call mysqli_real_escape_string even if it feels like it's not necessary: Anybody reviewing your code who sees a lack of calling that function would otherwise spend minutes/hours scrutinizing the code to check for possible attacks, perhaps searching through old logs, and unnecessarily worrying about whether they need to notify their entire customer base of a potential data leak.)

Even cartoons tell you to sanitize your SQL input.

Securing the data stored in the database.
Suppose we store passwords or credit-cards in our databsae. What might someday happen (inferring from headlines)? Sadly, somebody might breach the db itself (aside from the website entirely) — either a hacker exploiting a DB security hole, or somebody accidentaly revealing the DB account password, or an inside employee stealing data.

Solution: Don't store the password in the database!
“But Barland, how the heck can we verify that they've typed in the correct password?”
We'll instead store an encrypted form of the password. Then, when a user later types in the password on a form, we'll encrypt whatever they type, and see if the two encryptions are equal.

php > echo hash('sha256', 'hello');
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
php > echo hash('sha256', 'helmo');
05c21a42da66f4e2d217e35b74ef9dc2d65c8d46f9aec0d6397a65dd3c766f21

(Yes, theoretically, there is tiny (but non-quite-zero!) chance that two different strings might happen to encrypt to the same value. In practice, I would wait to win the lottery before I worry about two independently-chosen strings both happen to have hash-values that collide.)

Salt, to help protect against brute-force dictionary attacks.
Rather than md5 or sha1, Use crypt with sha256 or so.

For more details, read the php docs: us.php.net/manual/en/faq.passwords.php#faq.passwords.fasthash.

¹ Well, in this case, there are two other minor differences: to create the connection call “new mysqli(…)” instead of “mysqli_connect(…)”; and to check for errors look at the (string) field “$connect->connect_error” instead of checking for $connect being null. ↩

home—lects—exams—hws
D2L—breeze (snow day)

©2012, Ian Barland, Radford University
Last modified 2013.Apr.22 (Mon) Please mail any suggestions
(incl. typos, broken links)
to ibarlandradford.edu

lect10-ch12-mysql MySQLchapter 12

lect10-ch12-mysql
MySQL
chapter 12