Doctrine column types

I’m using Doctrine 2.1, and the only documentation I could find for column types in Doctrine was in the 1.2 documentation. I’ve been trying to use the ‘clob’ data-type that is listed there, but haven’t had any luck getting it to work. So what I’ve done instead is to use a ‘string’ data-type and override its columnDefinition with something like this:

@Column(type="string", nullable=false, columnDefinition="TEXT CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL")

It’s a pain because that causes the database updating script below to output column changes every time it is run:

php %doctrine% orm:schema-tool:update --dump-sql > update.sql

CodeIgniter xss_clean

While playing with CodeIgniter I bumped into its xss_clean function. Found this article on StackOverflow that discusses its use. Basically I don’t think I’ll be using it, rather I will be HTML encoding my data for inclusion in HTML output. Still have the sticky issue of what to do with comments, because in comments I allow for HTML. Maybe xss_clean will be useful there..? I’ll look into it a little more further down the track.

Cross-site scripting and HTML injection

Been reading about Cross-site scripting today on Wikipedia just to see if there was anything I didn’t already know. I’m in the process of code reviewing the entire Pcphpjs code base to remove all the XSS vulnerabilities that I left latent while hacking it together and learning the CodeIgniter and Doctrine frameworks. Now things are relatively stable so I’m going to go over the whole thing and refactor it with a view to code reviewing data handling for HTML injection while I’m at it.

JavaScript base64_encode

This is where all the trouble began. Back on July 19th this year I commented on the base64_encode function over at phpjs.org letting them know about a bug in their function whereby they were encoding as UTF-8 (whatever that means) prior to doing the Base64 encoding, which is a bug. Anyway, I had to patch the code myself for its use in pccipher and after several months no-one at phpjs has fixed up the implementation. So, that makes me mad, and when I’m mad, I fork!

I forked ProgSoc into ProgClub, and now I’m forking phpjs.org into jsphp.co. Both times it was because there was something going on that gave me the shits and I felt as if I could do a better job. So far I’m really pleased with my results. One great thing about forking is that it encourages the other party to lift their game. I wouldn’t be surprised to see phpjs.org improve its features after they see what I’ve done with jsphp.co.

Update: I ended up fixing that base64_encode function. My notes are in the comments.