Drinkable Chicken

For what it’s worth, version 0.7 of Magi-Nation Search is online. This version contains all cards released in the US, including promos. (Or so it should be anyway… let me know if there are cards missing.)

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… ^_^)

Remember that old CCG Magi-Nation? Some kind soul has been working on a searchable card database (kind of like Gatherer for MtG) for this game… Magi-Nation Search. The site is still under construction, and a bit sluggish, but usable… and it uses Python as the query language! How cool is that? :-)

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.

This is great stuff: A Challenge To Break Python Security.

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.

I wanted to add custom filters to my Google App Engine application… There are instructions on how to do this in several places, but some of them contradict each other, and it took me a little while to get it working. Anyway, I thought I’d share the setup that did the trick for me.

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.

If I finish my Scheme interpreter (written in Python), and it comes out halfway decent, it would technically be possible to use Google App Engine with Scheme…

*ponders*

For what it’s worth, I’ve been tinkering a bit with Google App Engine. So far I like it… I especially appreciate that I can focus on writing Python code, rather than having to work around a traditional database’s rigidity. (You know… creating a database schema, and a model in an ORM to mimick it, then keeping them in sync, all the while pretending that you’re storing and retrieving objects rather than rows in tables.)

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. :-)