mirror of
https://github.com/aljazceru/CTFd.git
synced 2025-12-17 14:04:20 +01:00
adc70fb320
Alpha release of CTFd v3.
# 3.0.0a1 / 2020-07-01
**General**
- CTFd is now Python 3 only
- Render markdown with the CommonMark spec provided by `cmarkgfm`
- Render markdown stripped of any malicious JavaScript or HTML.
- This is a significant change from previous versions of CTFd where any HTML content from an admin was considered safe.
- Inject `Config`, `User`, `Team`, `Session`, and `Plugin` globals into Jinja
- User sessions no longer store any user-specific attributes.
- Sessions only store the user's ID, CSRF nonce, and an hmac of the user's password
- This allows for session invalidation on password changes
- The user facing side of CTFd now has user and team searching
- GeoIP support now available for converting IP addresses to guessed countries
**Admin Panel**
- Use EasyMDE as an improved description/text editor for Markdown enabled fields.
- Media Library button now integrated into EasyMDE enabled fields
- VueJS now used as the underlying implementation for the Media Library
- Fix setting theme color in Admin Panel
- Green outline border has been removed from the Admin Panel
**API**
- Significant overhauls in API documentation provided by Swagger UI and Swagger json
- Make almost all API endpoints provide filtering and searching capabilities
- Change `GET /api/v1/config/<config_key>` to return structured data according to ConfigSchema
**Themes**
- Themes now have access to the `Configs` global which provides wrapped access to `get_config`.
- For example, `{{ Configs.ctf_name }}` instead of `get_ctf_name()` or `get_config('ctf_name')`
- Themes must now specify a `challenge.html` which control how a challenge should look.
- The main library for charts has been changed from Plotly to Apache ECharts.
- Forms have been moved into wtforms for easier form rendering inside of Jinja.
- From Jinja you can access forms via the Forms global i.e. `{{ Forms }}`
- This allows theme developers to more easily re-use a form without having to copy-paste HTML.
- Themes can now provide a theme settings JSON blob which can be injected into the theme with `{{ Configs.theme_settings }}`
- Core theme now includes the challenge ID in location hash identifiers to always refer the right challenge despite duplicate names
**Plugins**
- Challenge plugins have changed in structure to better allow integration with themes and prevent obtrusive Javascript/XSS.
- Challenge rendering now uses `challenge.html` from the provided theme.
- Accessing the challenge view content is now provided by `/api/v1/challenges/<challenge_id>` in the `view` section. This allows for HTML to be properly sanitized and rendered by the server allowing CTFd to remove client side Jinja rendering.
- `challenge.html` now specifies what's required and what's rendered by the theme. This allows the challenge plugin to avoid having to deal with aspects of the challenge besides the description and input.
- A more complete migration guide will be provided when CTFd v3 leaves beta
- Display current attempt count in challenge view when max attempts is enabled
- `get_standings()`, `get_team_stanadings()`, `get_user_standings()` now has a fields keyword argument that allows for specificying additional fields that SQLAlchemy should return when building the response set.
- Useful for gathering additional data when building scoreboard pages
- Flags can now control the message that is shown to the user by raising `FlagException`
- Fix `override_template()` functionality
**Deployment**
- Enable SQLAlchemy's `pool_pre_ping` by default to reduce the likelihood of database connection issues
- Mailgun email settings are now deprecated. Admins should move to SMTP email settings instead.
- Postgres is now considered a second class citizen in CTFd. It is tested against but not a main database backend. If you use Postgres, you are entirely on your own with regards to supporting CTFd.
- Docker image now uses Debian instead of Alpine. See https://github.com/CTFd/CTFd/issues/1215 for rationale.
- `docker-compose.yml` now uses a non-root user to connect to MySQL/MariaDB
- `config.py` should no longer be editting for configuration, instead edit `config.ini` or the environment variables in `docker-compose.yml`
112 lines
4.9 KiB
ReStructuredText
112 lines
4.9 KiB
ReStructuredText
Deployment
|
|
==========
|
|
|
|
CTFd is a standard WSGI application so most if not all `Flask documentation`_ on deploying a Flask based application should apply. This page will focus on the recommended ways to deploy CTFd.
|
|
|
|
.. Important::
|
|
Fully managed and maintained CTFd deployments are available at https://ctfd.io.
|
|
|
|
Docker
|
|
------
|
|
|
|
CTFd provides automatically generated `Docker images`_ and one of the simplest means of deploying a CTFd instance is to use Docker Compose.
|
|
|
|
.. Caution:: While Docker can be a very simple means of deploying CTFd, it can make debugging and receiving support more complicated. Before deploying using Docker, be sure you have a cursory understanding of how Docker works.
|
|
|
|
1. Install `Docker`_
|
|
2. Install `Docker Compose`_
|
|
3. Clone the CTFd repository with ``git clone https://github.com/CTFd/CTFd.git``
|
|
4. Modify the ``docker-compose.yml`` file from the repository to specify a ``SECRET_KEY`` environment for the CTFd service. ::
|
|
|
|
environment:
|
|
- SECRET_KEY=<SPECIFY_RANDOM_VALUE>
|
|
- UPLOAD_FOLDER=/var/uploads
|
|
- LOG_FOLDER=/var/log/CTFd
|
|
- DATABASE_URL=mysql+pymysql://root:ctfd@db/ctfd
|
|
- REDIS_URL=redis://cache:6379
|
|
- WORKERS=4
|
|
|
|
.. Tip::
|
|
You can also run ``python -c "import os; f=open('.ctfd_secret_key', 'a+'); f.write(os.urandom(64)); f.close()"`` within the CTFd repo to generate a .ctfd_secret_key file.
|
|
|
|
5. Run ``docker-compose up``
|
|
6. You should now be able to access CTFd at http://localhost:8000
|
|
|
|
.. Note::
|
|
The default Docker Compose configuration files do not provide a reverse proxy server or configure SSL/TLS. This is left as an exercise to the reader by design.
|
|
|
|
Standard WSGI Deployment
|
|
------------------------
|
|
|
|
As a web application, CTFd has a few dependencies which require installation.
|
|
|
|
1. WSGI server
|
|
2. Database server
|
|
3. Caching server
|
|
|
|
WSGI Server
|
|
~~~~~~~~~~~
|
|
|
|
While CTFd is a standard WSGI application and most WSGI servers (e.g. gunicorn, UWSGI, waitress) will likely suffice, CTFd is most commonly deployed with gunicorn. This is because of its simplicity and reasonable performance. It is installed by default and used by other deployment methods discussed on this page. By default it is configured to use gevent as a worker class.
|
|
|
|
|
|
Database Server
|
|
~~~~~~~~~~~~~~~
|
|
|
|
CTFd makes use of SQLAlchemy and as such supports a number of SQL databases. The recommended database type is MySQL. CTFd is tested with and has been installed against SQLite, Postgres, and MariaDB.
|
|
|
|
By default CTFd will create a SQLite database if no database server has been configured.
|
|
|
|
.. Note::
|
|
CTFd makes use of the JSON data type which your database backend must support.
|
|
|
|
.. Note::
|
|
CTFd is typicaly used with MySQL, MariaDB, or SQLite. Using CTFd with Postgres is uncommon and could be deprecated in any version. Even though Postgres may be part of the CTFd test suite, using Postgres as your database backend is at your own peril. Any issues raised regarding Postgres support will carry the expectation that the issue author write an accompanying pull request to resolve said issue.
|
|
|
|
Caching Server
|
|
~~~~~~~~~~~~~~
|
|
|
|
CTFd makes heavy use of caching servers to store configuration values, user sessions, and page content. It is important to deploy CTFd with a caching server. The preferred caching server option is Redis.
|
|
|
|
By default if no cache server is configured, CTFd will attempt to use the filesystem as a cache and store values in the ``.data`` folder. This type of caching is not very performant thus it is highly recommended that you configure a Redis server.
|
|
|
|
Vagrant
|
|
-------
|
|
|
|
CTFd provides a basic Vagrantfile for use with Vagrant. To run using Vagrant run the following commands:
|
|
|
|
::
|
|
|
|
vagrant up
|
|
|
|
Visit http://localhost:8000 where CTFd will be running.
|
|
|
|
To access the internal gunicorn terminal session inside Vagrant run:
|
|
|
|
::
|
|
|
|
vagrant ssh
|
|
tmux attach ctfd
|
|
|
|
.. Note::
|
|
|
|
CTFd's Vagrantfile is not commonly used and is only community supported
|
|
|
|
Debug Server
|
|
------------
|
|
|
|
The absolute simplest way to deploy CTFd merely involves running `python serve.py` to start Flask's built-in debugging server. This isn't recommended for anything but debugging and should not be used for any kind of load. It is discussed here because the debugging server can make identifying bugs and misconfigurations easier. In addition, development mostly occurs using the debug server.
|
|
|
|
.. Important::
|
|
CTFd makes every effort to be an easy to setup application.
|
|
However, deploying CTFd for large amounts of users can be difficult.
|
|
|
|
Fully managed and maintained CTFd deployments are available at https://ctfd.io. If you're interested in a specialized CTFd deployment with custom features please `contact us <https://ctfd.io/contact/>`_.
|
|
|
|
|
|
.. _Flask documentation: http://flask.pocoo.org/docs/latest/deploying/
|
|
.. _Docker images: https://hub.docker.com/r/ctfd/ctfd/
|
|
.. _Docker: https://docs.docker.com/install/
|
|
.. _Docker Compose: https://docs.docker.com/compose/install/
|
|
.. _contact us: https://ctfd.io/contact/
|