I have a rough proof of concept! Man though, precompiled queries in php are brittle. And it looks like YUI is going away. Time to learn Angular, I guess. Still, there is enough in the demo I think to start gathering data and analyzing a bit.
Lots more to come 🙂
Ok, things are getting close. I have all the code pieces talking in a single application (http://philfeldman.com/irev1.html). After playing around with the ways that the key down/up events can be trapped, I decided to do as little processing as possible and simply record the keycode, time and status (up/down). The main reason for this is that things like the shift key are pressed while other keys are typed and then released. This way it’s easier to see that happen.
I also needed to prevent pasting, since that makes everything more complex (recognizing paste events, working around them, etc). It turns out that YUI dosn’t seem to handle the paste event, so you have to get it from the document directly:
var pasteTrap = document.getElementById('submittedTextInput');
pasteTrap.onpaste = function(e){
alert("Paste is not allowed");
return false;
}
As usual, we have the fine contributors to StackOverflow to point the way to do this
Amazingly, it even works in all browsers.
Next is cleanup, putting all the pieces into modules where they belong and doing some better css. I think something like secret might be pretty easy to put together. Colored backgrounds before coding up picture loading. But along those lines.
Last thing for the day is to finish the next pass at the IRB submission.
If you want to reduce the likelihood of a SQL injection attack, use, precompiled queries. Nice in theory, tougher in practice. The nub of the problem appears to be the way that PHP binds data to execute the insert or the pull. With a nice, vulnerable query you can use string manipulation functions and as such make nice, general functions. However, if you’re mean, you can add something like “;DROP TABLE students; and poof, the table students is gone. Now, there should be a nice call that returns everything as an associative array, but that doesn’t seem to be reliable across PHP installations, so we need to work with the much more restrictive fetch();
Things to remember:
Anyway that just about doubled the line count in the middleware and bound the PHP code much more tightly to the form of the database. That being said, this is intended to have some production values in it anyway, so that may be a good thing. The new and improved results are in the same old place, namely io2.html. Next comes the integration of all that DB work, the recognizer part, and the panel part.
Not much to write about, but some good work got squeezed in today. First, I was able to transition over to mysqli, which turned out to be nearly painless. I’ve been working on a thin layer that’s admittedly got some security holes, but that’s not what I’m trying to work through and the data’s junk anyway.
So to get use out of all this stuff, I need to have everything run on a server. I use Dreamhost, who I like a lot and have been with for years, and they give you PHP and mysql out of the box. So today was the day to try and take all the pieces that I have gotten working on my dev machine and migrate them to a place that people can access.  It did mean getting familiar with SSH and PuTTY all over again though.
The first step was creating a database. Since I’m on a shared server, that’s not as simple as when you own the instance, but Dreamhost has a dashboard that makes this pretty reasonable. It does take time though for everything to trickle through though. Once it was up and running I created a new copy of the same old table I’ve been using for my tests and populated it with the same old data.
Once that was done I fired up WinSCP and copied the files over, changed the config file and tried running the php script on the command line. Imagine my surprise when everything ran right the first time. And then compound that again when the web page worked as well. And both of those files had no changes. Repeat after me:
“Configuration files are wonderful”
“Relative addressing is also”
Anyway, here it is in all its glory: io2.html.
The next part is handling the submission of data to the db, which is making me a bit nervous about sql injection. I may just use the YUI Escape object to modify the string so it isn’t dangerous. Nope, that won’t work, but we can use blobs. Here’s how (from here):
/**
* update the files table with the new blob from the file specified
* by the filepath
* @param int $id
* @param string $filePath
* @param string $mime
* @return boolean
*/
function updateBlob($id,$filePath,$mime) {
$blob = fopen($filePath,'rb');
$sql = "UPDATE files
SET mime = :mime,
data = :data
WHERE id = :id";
$stmt = $this->conn->prepare($sql);
$stmt->bindParam(':mime',$mime);
$stmt->bindParam(':data',$blob,PDO::PARAM_LOB);
$stmt->bindParam(':id',$id);
return $stmt->execute();
}
On a related note, I wonder how many of our actions can be stereotyped in a way that can be detected in the browser?
We are packing up, so I’m done for now. Progress has been pretty good. The core parts of the posting module are done, though they are not yet managed by a “topic manager” or some similar. I have YUI talking via PHP to MySQL, sending objects that contain data that will be needed in a structured way. That turned out to be much harder than I thought, simply because I couldn’t make the debugger in IntelleJ work in the PHP server file in such a way that I could watch an HTTP request come in. In olden days, I would have RTFM about the process and worked from that, but now with OpenSource, I’ve become very dependent on the debugger to tell me what’s actually going on. Many times things don’t correspond with (often stale) documentation. So in the end, I put together a light PHP class that pretty much echoed POST calls back at me so that I could look at them in the JavaScript debugger. That burned a day. Sigh.
The last (new) thing to do is to make the database access robust. I did my code based on Learning PHP, MySQL, and JavaScript, a generally fine book, but it still uses the deprecated “mysql_*” calls. I need to update that and have some generalized data return structures built. Then that part should be reasonably static from here on out.
It’s vacation so I must be coding. Today it’s outside with a lovely view of the rolling hills surrounding Deep Creek Lake.
I’m working on getting all the pieces for the first version of the Recognizer working. The goal is to have a webapp that allows for original  “posts” or “comments” that pertain to a post. I’m thinking that both of these can be handled in the same table:
CREATE TABLE IF NOT EXISTS `session_table` (
`uid` int(11) NOT NULL AUTO_INCREMENT,
`session_id` varchar(255) NOT NULL,
`type` int(11) NOT NULL,
`entry_time` datetime NOT NULL,
`ip_address` varchar(255) NOT NULL,
`browser` varchar(255) NOT NULL,
`referrer` varchar(255) NOT NULL,
`submitted_text` text NOT NULL,
`raw` text NOT NULL,
`parent_session_id` varchar(255) DEFAULT NULL,
`veracity` int(11) NOT NULL,
PRIMARY KEY (`uid`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
There is extra data being stored here (browser, ip, etc) simply because it will make correlations potentially easier at this state when I have little idea what works. I’m also storing the raw data along with the post so it can all be processed later, in multiple ways. At this point, the intent is to save the raw data as key/value pairs in JSON, mostly because it’s easy to make that conversion using Y.JSON.stringify.
The other thing that I’ll need to organize the posts/comments is a topic table. I think that for the time being, it can be taken from the title of the first post. Comments can then point to the topic, and that allows for filtering of what to see. Additional filleting at this level can be keywords, trustworthiness, location, etc.
Phlog 