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
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.
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.
Found out about the YUI PHP Loader the other day. Haven’t used it yet, but looks like something I should check out.
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.
I’ve been learning about how to create forms using CodeIgniter and its Form Helper subsystem.
Finally starting to get my head around Doctrine‘s Association Mappings. In the jsphp.co project I’m using one-to-one, one-to-may, many-to-one, and many-to-many relationships now, so I’ve got an example of everything.
I cheated with the design of the jsphp.co web-site and used a layout from this article CSS layouts. I use a slightly customised version of the one column fixed width layout and the two column fixed width layout.
I’m working on my jsphp.co web-site. I haven’t deployed my latest changes yet, so there’s nothing there on the main web-site just now, except if you head over to checkout the development area which has all my latest changes. Basically over the last couple of days I’ve added support for:
- Home page
- Category listing
- Function listing
- View function, tests and benchmark with linkable line numbers
- Edit function, tests and benchmark with summary
- Test the code using QUnit
- Benchmark code and compare versions
- List revisions and view, edit or change the release status
- List developers including local and upstream contributors
- Comments on functions or tests (incomplete)
- Link to features, such as code downloads or the phpjs.org implementation
- Administer the function
- Contributor listing
- Lists local contributors
- Lists upstream contributors
- Licensing info
- Links to other web-sites
- Contact information
- System administration
- Manage categories
- Manage functions
- Manage users
- Manage upstream developers
- View errors
There’s still a little bit to do. Basically I need to review the entire code base for HTML injection and XSS vulnerabilities, I need to fix up the commenting subsystem to allow for editing and creation of comments, I need to protect from some changes (e.g. only administrators can release a function version), many of the forms need better/reviewed workflow for errors and omissions, there needs to be a facility for adding and removing upstream developers, and that’s about it. Once I’ve got those planned changes done I’ll release the latest version of the site and begin the process of importing the phpjs.org code base.