Also, it now has its own project page. (This is a modest start of the new project site, which should eventually replace the old labs page. Yes, it looks like ass in Internet Explorer… but then again, who uses IE nowadays anyway? :-)

(It’s small stuff, but I would love to do a version for L5R, or something, someday… ^_^)

Update: As it turns out, that version was dog slow, due to the initial loading of cards which took 14s on my machine. >.< A new version, which takes 0.5s, is available now.

The challenge is simple:

• Open a fresh Python interpreter and do:

  >>> from safelite import FileReader

• You can use FileReader to read files on your filesystem
• Now find a way to write to the filesystem from your interpreter

This has been discussed extensively for the last few days on python-dev. It’s funny how code seems to be pretty secure at first glance, then someone comes up with another loophole.

It especially piqued my interest since I am working on yet another searchable card database, this time using Google App Engine. Kind of like Gatherer, but for a different CCG than Magic, and (hopefully) more flexible. What does this have to do with security? Simple: the most flexible way to search cards is to store them as Python objects, then search them using a Python expression, e.g.

card.red and card.black and (card.creature or card.instant) and card.cost > 2

…or, a more convoluted query:

(card.red or card.black) and not card.multicolor \
and card.type == 'Dragon' and card.set.year > 2006

Now, executing an arbitary Python expression entered on a web page, is of course very unsafe. So I need to find ways to make it more secure, while still preserving the flexibility of a Python-based search. Although I’m not sure how much it matters in this particular case, because:

• According to the App Engine docs, an application cannot write to the system, so no overwriting of files (?).

• I’m not using the data store at all, and there is no user registration, so there’s no sensitive data to be accessed or manipulated.

• Projects like Try Python and Try Ruby seem to fare pretty well without imposing many restrictions on the user.

That said, there might be other ways to mess with the site. Personally I don’t care if a user manages to screw up their own session due to malicious hackery, as long as it doesn’t affect other users. :-)

Anyway, the site isn’t ready yet, I still need to add more cards and flesh out the API. If you want to try it (locally), drop me a note, and I’ll send you the code.

Let’s say your application is in a directory app. Create a directory app/common. Drop an empty __init__.py in it, and the file containing your filters; say, my_filters.py.

Here’s some sample code for app/common/my_filters.py:

from google.appengine.ext import webapp

register = webapp.template.create_template_register()

@register.filter
def foobar(value):
    return "(%s)" % str(value)

This creates a simple (and rather useless :-) filter named foobar, that takes an argument and returns its string values, surrounded by parentheses. register.filter can be used as a decorator. Any functions in the file that are not registered, will not be recognized as filters.

In the application’s main file, add the following (at the toplevel):

from google.appengine.ext.webapp import template

template.register_template_library('common.my_filters')

Now, in your templates, you should be able to do things like

{{ "hello"|foobar }}

That’s all. I saw some explanations online that talked about using the templatetags directory and such, but that doesn’t seem to be necessary with App Engine.

*ponders*

Of course, for all I know GAE does exactly that behind the scenes, but it *feels* different. So far, I find it much more pleasant to work with than “regular” web application frameworks. Maybe this statement reveals my inexperience with web programming, but still, that’s what it feels like right now. :-)