Implementation of a database for mathematical problems, developed for Wurzel e.V.
The idea was to provide a database for 40 years of collected problems, to make them available to the public, searchable, and trackable for intern purposes. Since the mid-1960s, authors can submit problems to the Wurzel, which publishes six of them every month. Readers can propose solutions, which are published later as well.
The idea of a problem base was born out of the following thoughts:
- Given that there are thousands of problems, some with solutions, available in archives, why not make them publicly available - to teachers in universities and high schools, to interested students?
- Every once in a while, problems are submitted which have been published
long before. How can we find that out easily? It is relatively hard to
grepthe TeX archive when looking for a problem. Is there a better way? Sure. - Sometimes one wants to find problems of a specific type, say number- theoretic or geometric problems. That would be especially attractive for teachers.
- Not every problem that seems simple is. And the same goes for hard- looking ones.
- Incoming problems usually get sorted into piles like "rejected", "for later", "nice but too easy" and so on. Is there a better and more transparent way?
- Some problems get never published though they are not so bad, actually. Sometimes there's just too many coming in.
That's where the problem base enters the game. Simply a SQLite database, easily accessible through a PHP frontend. A web frontend seemed plausible, as the database can be accessed from different locations, and - originally - to be OS independent. We feature:
- Multiple proposers per problem - or none at all. Please provide some remarks then.
- Solutions connected to problems
- Tagging: they might tell what area of mathematics the problem belongs to
- Comments: give some quantified evaluation about difficulty, beauty, and required knowledge of the problem. And say a few words about how you liked it.
- Full-text search: technically, it's not a feature of pb but of SQLite. Anyway, you might find it useful!
- Live TeX preview - thanks to MathJax
- Beautiful design using HTML5, CSS3 and JavaScript.
The problem base runs on Apache+PHP or nginx+PHP-FPM, supported by a SQLite or PostgreSQL data base. Get a clone by
git clone --recursive git://github.com/wurzeljena/problembase.git
You can either clone into the document root or a subdirectory. In this case,
add an environment variable PBROOT=/path/to/problembase. Also, add
ErrorDocument 403 /path/to/problembase/error403.php
ErrorDocument 404 /path/to/problembase/error404.php
to your httpd.conf or similar lines for nginx. If you use Apache, you might
also want to "compile" the .htaccess files into your httpd.conf. (e.g, by
using htaccessConverter)
This speeds up your server a bit. Don't forget to adapt the RewriteRules to
your needs.
The nginx server should be configured to handle PHP scripts via PHP-FPM. Apart
from that, a pretty basic configuration should work, don't forget to include
conf/nginx_app.conf in the server directive, between server, root etc.
and the code passing PHP files to the FPM server.
Since we are likely dealing with a small number of users, a SQLite database is sufficient. It also makes backups easy. Create the database as follows:
cd sql
sqlite3 -init sqlite.sql problembase.sqlite
In the opening prompt, create a root user:
INSERT INTO users (name, email, root, editor) VALUES ("Your name", "[email protected]", 1, 1);And we're done: open http://localhost/path/to/problembase (which might just
be http://localhost/) and enjoy! Don't forget to set a password for your
first user.
If you expect more users or want to use a separate database server for some
other reason, PostgreSQL is also supported.
Create the tables etc. by executing sql/postgres.sql. Create an initial user
as above.
To set up the connection, simply set environment variable DATABASE_URL to
postgres://username:password@host:port/dbname
Although the UI should be straightforward and intuitive, some remarks:
- We rely on JavaScript. Don't deactivate it.
- Users with editor rights can do (almost) anything: edit and delete
problems, solutions, write comments. So be careful! But only a
rootuser can add users and grant (or revoke) rights. - There is no history kept and no backlog of changes to the databases. Hence there is no built-in way to revert to an older state. Until there is, be careful to whom you grant which rights and backup the database regularly.
- By using CSS media queries, the layout works on every device. That is, if the device happens to support media queries.
Yeah, whatever. I could as well explain it, maybe later.
- Play with it,
- take a look at sql/sqlite.sql
- and .htaccess or conf/nginx.d/rewrite.conf. As of now, the "API" is not documented anywhere.
- Read the source. It's not that much.
Though no terrible things should happen, it is recommended to use a recent browser. I do not test again IE 6 or the like. Since HTML5 provides graceful fallback, the pages should not be interpreted erronously in older browsers, but they might not display as beautiful.
As of now, full HTML5 compliance is not guaranteed. It's definitely on the list, though.
Some effort has been made to ensure that unauthenticated users can't do any harm to the database. However, as authenticated user, you can do a lot. So please backup every once in a while, dear admin. You won't regret. However, thorough security checks still have to be done. Feel free to analyse the code, I'll be happy about critical feedback.
Passwords are stored as salted SHA-512 hash. To prevent password guessing, one has to wait for 10 seconds after a failed attempt.
Take a look at the GitHub issues page. If you think you can solve one, do it. Then send a pull request. If you experience some other issues, please add them or email me. The list is by far not comprehensive, sometimes I don't write problems down when I think they can be solved quickly.