FluxFingers Scoreboard Documentation¶
Welcome to the almighty FluxFingers scoreboard! Behold fools for you will experience the power of the FluxFingers that will bring you joy and love when running your own CTF or competition.
Come Again?¶
Running a CTF is hard. Designing challenges is hard. Providing a stable infrastructure is hard. But a scoreboard should not be hard, it should be the easiest part of hosting a CTF.
So here it goes: A hopefully simple solution so you can run your own CTF (or different competition). To get you started head over to Getting Started! Otherwise, take a look at the table of contents below.
Oh and you can find our Source Code hosted on GitHub.
Documentation for Users¶
Documentation for Developers¶
Warning
The developer documentation has not been updated for some time. It likely contains outdated or invalid information. You can use it as a reference but if in doubt between code and documentation, follow the code. This would need someone to look at it but who would want to do that?
Here is a high level overview of the project:
/alembic/contains the database migration files. Like, when your database wants to migrate to different countries or something along the lines of that./cfg/contains all the configuration. Good configurations will be automatically generated by therunscript./data/contains all other data sources needed for the installation./docs/contains documentation of the project (javex tries to keep up with documenting stuff, qll writes godlike code which documents itself exclusively to himself)./fluxscoreboard/contains the actual Pyramids project. Please don’t look inside it. I really don’t want to explain all folders in there, too :-//log/contains all log files. That one is cleverly named, huh?./tests/contains all unit tests./tmp/I DON’T EVEN KNOW WHAT IT CONTAINS LOL.
Installation¶
After accepting that you are unworthy of setting up the project by yourself, you’ll find the run script helpful. The only thing you have to do is:
./run install development
Isn’t that a nifty bad boy? It asks you everything it needs. So. Cool. I wonder what kind of genius wrote this. Make sure you execute this in a virtual environment. If you really can’t help it pass the –no-venv flag to skip the virtual env check.
You can then execute the following command to execute all unit tests:
./run test
Finally you might want to take a look at this sexy web application. The following command will run a development server on port 6543.
./run serve
If you want to have greater control over the port and shit, run:
pserve cfg/development.ini port=8000
The API documentation basically dumps docstrings into here. And some functions don’t even have that. Look at it, cherish that there is something. Then look at the code, it might speak to you.