StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
7255796
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
14
CommunityOwnedDate
CreationDate
2011-08-31T10:40:49.360
FavoriteCount
0
LastActivityDate
2011-08-31T13:34:07.707
LastEditDate
2011-08-31T13:34:07.707
LastEditorUserId
568785
OwnerUserId
568785
ParentId
7255746
PostTypeId
2
Score
2
ViewCount
0
LastEditorDisplayName
text
Body
The result is stored in the <code>$result</code> array, not the PDO object <code>$one</code>. This also needs an echo if you're not going to use shorttags. <pre><code><input type="text" placeholder="<?php echo $result['gr_name']; ?>"> </code></pre> I'd use shorttags, so if you PHP setup has them enabled, but they are being deprecated in PHP 5.6: <pre><code><input type="text" placeholder="<?= $result['gr_name']; ?>"> </code></pre> You can use shorttags for now, and I will continue to use them to protest the removal of this incredibly useful feature. Deprecating shorttags will break a lot of WP themes and simple template engines! You should also consider using <a href="http://php.net/manual/en/pdo.prepared-statements.php" rel="nofollow">prepared statements</a>. Without them, this script is vulnerable to SQL injections. <pre><code><?php $query = $pdo->prepare("SELECT * FROM contactgroups WHERE id=:id"); if( $query->execute(array(':id' => $_GET['id'])) ) { $result = $query->fetch(); ?> <input type="text" placeholder="<?php echo $result['gr_name']; ?>" /> <?php } ?> </code></pre> How PDO Prevents SQL Injection (too long to put in a comment - scroll down to see a better explanation) Let's begin with a query: <pre><code>mysql_query("DELETE FROM users WHERE id='".$id."'"); </code></pre> If <code>$id = "' OR 1=1 --";</code> then the query would look like this when sent to MySQL (-- signifies the start of a comment): <pre><code>DELETE FROM users WHERE id='' OR 1=1 --' </code></pre> Obviously, the destruction that would follow could be catastrophic and possibly unreversible (unless you've got some smart DB admins). The fix here instead of using the lengthy, <code>mysql_real_escape_string()</code> (I really never understood why the function name was so wordy in the first place), we can now use PDO prepared statements. By <a href="http://php.net/manual/en/pdo.prepare.php" rel="nofollow"><code>PDO::preparing()</code></a> a statement you are sending a message to your DB telling it to store and optimize this query because it will be used later. Your DB stores an optimized query, taking careful note of where the data belongs. <pre><code>$statement = $pdo->prepare('DELETE FROM users WHERE id=:id'); </code></pre> PDO will give you an instance of <a href="http://www.php.net/manual/en/class.pdostatement.php" rel="nofollow">PDOStatement</a> that you can <a href="http://php.net/manual/en/pdostatement.bindparam.php" rel="nofollow"><code>PDO::bindParam()</code></a> values to and execute. So let's do that and execute. <pre><code>$statement->bindParam(':id', $id); $statement->execute(); </code></pre> Now some behind the scenes magic happens here. PDO sends the data to MySQL. MySQL examines the data and inserts into the prepared statement. By knowing where the data was supposed to be placed and how long the inserted data was, MySQL can determine the character ranges in a query that don't need execute (read: the data). So, when a hacker tries an SQL injection, MySQL doesn't even worry about evaluating anything that is bound to the prepared statement. <ol> <li>PDO says to MySQL, <code>"The data for :id is ' OR 1=1 --"</code></li> <li>MySQL finds the location where :id was in the prepared statement. (In this example, character 28)</li> <li>MySQL counts the length of the data (In this case, 11 characters)</li> <li>MySQL does 1st grade math and remembers that it should treat everything from character 28 to 39 as characters.</li> <li>MySQL inserts the data and now the query looks like this: <code>DELETE FROM users WHERE id=' OR 1=1 --</code></li> <li>However, because it knows the position of the data, MySQL only analyzes everything outside of the pipes (|) for commands and keywords. <code>DELETE FROM users WHERE id=|' OR 1=1 --|</code></li> </ol> So the text between the pipes never actually gets analyzed. When MySQL needs compare id's it still compares id's in the table with the data, but since the data was never executed, the SQL injection fails. <h1>A Better Explanation of How PDO Prevents SQL Injections</h1> When we prepare a statement with PDO, it notifies the database of the upcoming query and where the data will be in the query. When we bind data to that query and execute it the database does some behind the scenes work to make sure that SQL injections are thwarted. Let's take this behind the scenes work to another context. You manage a PHP blog whose engine you wrote entirely by yourself. You are proud of the clever comment system you wrote until some jerk decides to post this comment: <pre><code><script type="text/javascript"> alert('You just been H4X0RED!!!!1 LOLS'); </script> </code></pre> After you yell some four letter words at the computer screen and make sure that the script kiddie's parents never let him on the internet again, you solve the XSS vulnerability in your code with <code>htmlspecialchars()</code>. <pre><code>$comment_text = htmlspecialchars($_POST['comment_text']); </code></pre> Now what have you done here? When the script kiddie wakes up at 3 AM and sneaks down to his computer to try the code again, <code>htmlspecialchars()</code> turns his lame attempt at humor into a jibberish mess. The function takes any character that is important in HTML (namely the <code><</code> and <code>></code>) and turns them into their literal value (<code>&lt;</code> and <code>&gt;</code>). <pre><code>&lt;script type=&quot;text/javascript&quot;&gt; alert('You just been H4X0RED!!!!1 LOLS'); &lt;/script&gt; </code></pre> The HTML parser in everyone's browser interprets the <code>&lt</code> not as the beginning of an HTML tag, but as a sign to actually output the character <code><</code>. This is essentially what the database engine does with all data inputted into prepared statements. Except since in SQL letters make up valid commands (and also valid data), the engine interprets all characters in the data as their literal value. So instead of: <pre><code>DELETE FROM users WHERE id = 0 OR 1=1 --' </code></pre> It evaluates each character in the data as it's literal value. In HTML that would be: <pre><code>DELETE FROM users WHERE id = &#48;&#32;&#79;&#82;&#32;&#49;&#61;&#49;&#32;&#45;&#45;&#39; </code></pre> If you look at <a href="http://jsbin.com/ujulak/edit#html,live" rel="nofollow">both here</a>, they both output the same thing, except in the second, the 'data' is being interpreted as it's literal value by the parser and not it's functional value. The SQL does the same thing. By using the literal value of the data, none of the actual data can be interpreted as a command or part of one.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POphp SQL PDO->Fetch() issue
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USBailey Parker
UserOwnerUserId
1. USBailey Parker
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POphp SQL PDO->Fetch() issue
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.