Tech Blog » User input http://assanka.net/content/tech Just another Arb-assk2009003.turmeric.assanka.com Blogs weblog Mon, 29 Aug 2011 19:00:46 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 Validating HTML input in PHP http://assanka.net/content/tech/2009/10/10/validating-html-input-in-php/ http://assanka.net/content/tech/2009/10/10/validating-html-input-in-php/#comments Sat, 10 Oct 2009 11:51:41 +0000 Andrew Betts http://assanka.net/content/tech/?p=38 It’s often the case that as web developers, we need to ‘clean’ input from end users to ensure it does not contain any nasty formatting or script that we don’t want to allow on our sites. Forums in particular often suffer from either security holes that allow cross site scripting attacks (XSS) or are so restrictive in what they allow to be input that it causes a nuisance to the user (for example, disallowing all HTML but allowing BBCode instead).

This problem is often solved with complex classes or functions in PHP that are designed to strip out the nasty stuff while allowing as much useful formatting as possible. We realised that these functions are pretty much just reinventing the wheel, because there is already a pretty good mechanism for parsing and validating XML syntax: libxml, which has PHP bindings and can be accessed using SimpleXML.

What’s more, libxml can parse an XML document for conformance to a DTD, so if you include an XHTML Transitional DTD in your XML code string, you can check that the markup is valid XHTML.

Here’s the PHP to do this. This is tested on PHP 5.3 with libxml2-2.6.26-2.1.2.8.

function isXML($str) {
	libxml_use_internal_errors(true);
	libxml_clear_errors();
	$options = (strpos($str, '<!DOCTYPE') !== false) ? (LIBXML_DTDLOAD + LIBXML_DTDVALID) : 0;
	simplexml_load_string($str, 'SimpleXMLElement', $options);
	$errors = libxml_get_errors();
	return (empty($errors) or $errors[0]->level == LIBXML_ERR_WARNING) ? true : false;
}

You could of course use the contents of $errors to feed back to the user, or potentially deal with a validation failure more intelligently, but for now true or false will do.

So the markup submitted by a user is valid. Excellent. But just because the markup is valid doesn’t mean it’s safe to output to the browser. You’ll also want to ensure it contains no <script type="text/javascript"> sections or event handlers, and may want to restrict the set of elements available. This is where you can start getting creative with your own DTD spec. Just start with the standard you want to conform to for the whole page (say XHTML) and strip out anything you don’t like.

We’ll start by removing the HEAD tag and all its contents. Our users will not be writing entire documents, just fragments of body markup, so we don’t want a HEAD, TITLE, or any META tags, etc.

You can continue, removing things like SCRIPT, OBJECT, forms, frames, and so on. Be careful where elements are defined using presets, which often contain the nasties, for example the %event set of attributes grants an element the ability to fire event handlers. Fortunately this is almost exclusively used as part of %attrs, so we can just remove it from that superset.

We’ll also define a new root element fragment_under_test to ensure that we don’t cause any confusion and lead anyone to believe that they’re writing a normal <html> or <body>.

Once we’re done, we can then wrap the isXML function in a convenience function that adds our new custom DTD.

function isXHTMLFragment($str) {
	return isXML("<!DOCTYPE fragment_under_test system \"http://www.example.com/dtds/xhtml-content-restrictive.dtd\"><fragment_under_test>".$str."</fragment_under_test>");
}

If you want, feel free to download the DTD I created for this article.

Now you can use the fast libxml to validate user input in a fairly bulletproof way.

Finally, and very importantly, make sure you cache the schemas on your server in an XML catalog file. If you don’t do this, libxml will make an external HTTP request for the DTD schema file every time you call the function. In fact, since most web documents cite W3C DTDs, they are having enormous problems with software making repeated requests for the standard XHTML, HTML 4 etc DTDs which haven’t changed in years. Be a good net citizen, and cache your schemas. In this case we’re writing and hosting our own anyway, but if you’re using a public schema you may as well save yourself the pointless HTTP traffic, and it’ll speed up the validation as well.

]]> http://assanka.net/content/tech/2009/10/10/validating-html-input-in-php/feed/ 0 Auto growing textareas http://assanka.net/content/tech/2009/05/04/auto-growing-textareas/ http://assanka.net/content/tech/2009/05/04/auto-growing-textareas/#comments Mon, 04 May 2009 16:24:52 +0000 Andrew Betts http://assanka.net/content/tech/?p=3 This feels like a topic that’s been explored to death already, but I really don’t like most implementations of this technique, so here’s how we do it.

First, in case anyone has just arrived from Mars, or even more unlikely, isn’t familiar with Facebook, the auto-growing textarea is a text box that gets bigger as you type into it, so that you never see a scroll bar (unless you’re typing war and peace).

There are lots of ways of doing each part of this. The parts I’ll look at are (a) what triggers a review of the text box’s size, (b) how to determine whether a resize is required, and (c) how to perform a resize.

Triggering a review

There are four ways this is typically done:

  1. On an interval, say every 50ms
  2. On keypress
  3. On change
  4. On keyup

I’m staggered by how many scripts insist on doing this kind of thing on an interval. Setting up interval timers for no good reason is a shortcut to terrible performance and memory leaks galore. So we won’t be doing that. onkeypress and onchange events are triggered before the box is updated with the latest keypress, so we want to avoid those, as the latest keypress might have been the one to bring us onto a new line. That leaves onkeyup, which is fired after the box is updated with the new character, and allows us to inspect it and decide whether to increase its size.

To resize or not to resize

How to determine whether to resize the box comes in three flavours:

  1. Count the number of newline characters in the textarea’s value, and see if that matches the number of rows the textarea has.
  2. Create a ’shadow’ DIV which is off screen (eg. margin-left: -10000px) and has no height declared, but otherwise has the same style properties as the textarea, fill it with the textarea’s content, measure the subsequent height of the DIV, then see if that height matches the current height of the textarea.
  3. Check whether scrollHeight (the height of the scollable content of the box) > clientHeight (the height of the box itself).

In this case I was suprised at the number of implementations that favoured counting newlines. This only works if combined with counting the number of characters in the textarea’s value, AND a monospaced font, AND knowing the number of columns in the textarea. In short, er, it’s mad.

Second option, and the one favoured by a lot of the framework plugins due to the ease with which you can create shadow elements in the likes of jQuery, is to create a shadow DIV. This has the advantage of telling you the actual pixel height of the text, even where it is LESS than the height of the textarea box. Otherwise, you’re limited to measuring clientHeight and scrollHeight, which are exactly the same if the textarea isn’t scrolling, regardless of how much space you’ve got to spare at the bottom. My issue with this method is that it basically requires use of a framework to not be painful, and even then it’s non-trivial amounts of code, and adds needless pollution to the DOM.

So that leaves relying on scrollHeight and clientHeight. These are well supported and efficient to read, so provided that you work around the issue of scrollHeight always being at least equal to clientHeight, this offers a very lightweight solution. The features that you can achieve with a shadow DIV that you can’t do by simply reading scrollHeight and clientHeight are (a) you can ensure there is always a blank line at the bottom of your textarea, and (b) you can shrink the textarea if the user deletes text from it. I’m personally of the view that neither of these is actually particularly desirable. There’s potentially an argument for leaving a blank line at the bottom, but equally the uer might feel like they’re just being pressured to write more.

How to resize the box

OK, so if you’ve concluded that the user is writing chapter and verse and the textarea is in need of a bit more space, how do we go about doing it?

  1. Animate the CSS height property
  2. Add some height via the CSS height property
  3. Add 1 to the rows attribute

A fair few of the framework plugins use their framework’s animation capabilities to animate the grow effect. I don’t like this. Just because you have an animation effect available doesn’t mean it’s appropriate to use it, and there are many situations where the end user just doesn’t want to wait 300ms for the privilege of using a fresh line.

Simply adding height to the CSS property is a fair way of doing it, but unless you do some maths on the user’s line height (or hard code some magic numbers), you can’t necessarily guarantee that the resulting height will be a multiple of the textarea’s line height.

Easiest, most efficient solution: add one to the rows attribute of the textarea. rows is part of XHTML as well as HTML 4.01, and has universal support going back yonks.

Pasting

Watch out for pastes. If the user pastes in a large quantity of text, they will trigger only one keyup event, but will have added many lines to the textarea. Make sure that if a resize is required, you trigger another review after the resize is complete.

Max height: the war and peace scenario

If the user really does seem to be writing a novel, we probably should call it a day on growing the textarea at some stage, and certainly before it gets to be taller than the viewport. You can check the height against the viewport height, though I typically just restrict it to an arbitrary height, say 30 rows.

The code

You’ll need a textarea element with an ID of mytextarea to make this code sample work, and obviously you can easily modify it to use selectors from your favourite framework rather than the native document.getElementById.

document.getElementById('mytextarea').onkeyup = function() {
	var ta = document.getElementById('mytextarea');
	var maxrows = 30;
	var lh = ta.clientHeight / ta.rows;
	while (ta.scrollHeight &gt; ta.clientHeight &amp;&amp; !window.opera &amp;&amp; ta.rows &lt; maxrows) {
		ta.style.overflow = 'hidden';
		ta.rows += 1;
	}
	if (ta.scrollHeight &gt; ta.clientHeight) ta.style.overflow = 'auto';
}
]]> http://assanka.net/content/tech/2009/05/04/auto-growing-textareas/feed/ 2