# Flagbase
This is the platform for TJCTF. It's (what I think is) the best of the MITRE,
CTFd, and picoCTF platforms rolled up into a Flask application.

I'm bad at naming things.

## Installation
You're going to want to edit `config.py`. The variable names should be fairly
self-explanatory.

You're going to want to create a file called `secrets`. It will look like this:

```yml
mailgun_url: https://api.mailgun.net/v3/tjctf.org
mailgun_key: key-asdflkjasdhflkjsdahflkhsdaklfjhasd
recaptcha_key: asdlkfjhasdlkjfhlsdakjfh
recaptcha_secret: sdakjfhsdalkfjhsdalkfjh
key: this can be anything you want, it is your flask secret_key
```

You should edit line 2 of database.py, unless you want to use SQLite. This uses
Peewee, so you can use any Peewee-supported database.

You can create some problem YAML files that look like this:

```yml
name: Problem Name
author: ME!
category: Binary
description: binary binary binary binary. i love binary
points: 250
flags: "flag{whatever}"
```

Then add them with `./ctftool add-challenge problem.yml` and it'll get put in the
database.

Run `python app.py` and you have a server running. You probably want to deploy
it with `gunicorn` or similar, long-term.

## ctftool

You can do some really fancy stuff with `ctftool`. If you have a directory structure
like this:

- ctf-platform
- ctf-problems
    - problem1
        - problem.yml
        - static.yml
    - problem2
        - problem.yml
        - static.yml
    - problem3
        - problem.yml
    - problem4

You can run `./ctftool scan ../ctf-problems/` and get a fully populated database
with information from all the problem.yml files, and automatically generated
static file names, and automatic substitutions for static file links in
problem.yml. More documentation on this to come soon.

## Contributing

Flagbase is under really heavy development right now. That means

- **Absolutely do** submit issues: bugs and feature requests are awesome.

- **Don't** submit a pull request for:
    - a major feature addition
    - database model changes

- **Do** submit pull requests for:
    - documentation addition/edits
    - minor bugfixes
    - small changes to existing features

If you're touching `database.py` or `config.py`, you're probably doing it wrong.

If you decide to ignore my guidelines, **write detailed documentation** on what your
pull request consists of, what problems it fixes, how it works, and what issues
it could bring up.

Of course, you are more than welcome to fork the repository.