Mercurial > p > roundup > code
view doc/mysql.txt @ 8575:b1024bf0d9f7
feature: add nonceless/tokenless CSRF protection
Add tokenless CSRF protection following:
https://words.filippo.io/csrf/
Must be enabled using use_tokenless_csrf_protection in config.ini. By
default it's off. If enabled the older csrf_* settings are ignored.
The allowed_api_origins setting is still used for Origin comparisons.
This should also improve performance as a nonce isn't required so
generating random nonce and saving it to the otks database is
eliminated.
doc/admin_guide.txt, doc/reference.txt doc/upgrading.txt
doc updates.
roundup/configuration.py
add use_tokenless_csrf_protection setting.
move allowed_api_origins directly after
use_tokenless_csrf_protection and before the older csrf_* settings.
It's used by both of them.
Rewrite description of allowed_api_origins as its applied to all
URLs with tokenless protection, not just API URLs.
roundup/anypy/urllib_.py
import urlsplit, it is used in new code.
urlparse() is less efficient and splits params out of the path
component.
Since Roundup doesn't require that params be split from the path. I
expect future patch will replace urlparse() with urlsplit() globally
and not need urlparse().
roundup/cgi/client.py
add handle_csrf_tokenless() and call from handle_csrf() if
use_tokenless_csrf_protection is enabled.
refactor code that expires csrf tokens when used with the wrong
methods (i.e. GET) into expire_exposed_keys(). Call same from
handle_csrf and handle_csrf_tokenless. Also improve logging if this
happens including both Referer and Origin headers if available.
Arguably we dont care about CSRF tokens exposed via
GET/HEAD/OPTIONS in the tokenless case, but this cleans them up in
case the admin has to switch back. At some future date we can
delete all the nonce based CSRF from 2018.
Update handle_csrf() docstring about calling/returning
handle_csrf_tokenless() when enabled. Call
expire_exposed_keys(method) if token is supplied with wrong method.
roundup/cgi/templating.py
disable nonce generation/save and always return "0" when
use_tokenless_csrf_protection enabled.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Sun, 19 Apr 2026 20:50:07 -0400 |
| parents | 3d7292d222d1 |
| children |
line wrap: on
line source
.. index:: mysql; deployment notes ============= MySQL Backend ============= This notes detail the MySQL backend for the Roundup issue tracker. Prerequisites ============= To use MySQL as the backend for storing roundup data, you also need to install: 1. MySQL RDBMS 8.0.11 or higher - https://www.mysql.com/. Your MySQL installation MUST support InnoDB tables. 2. Python MySQL interface - https://pypi.org/project/mysqlclient/ Preparing the Database ====================== The Roundup user expects to be able to create and drop its database when using ``roundup_admin init``. In the examples below, replace ``roundupuser``, ``rounduppw`` and ``roundupdb`` with suitable values. This assumes you are running MySQL on the same host as you are running Roundup. If this is not the case, setting up remote credentials, SSL/TLS etc. is beyond the scope of this documentation. However examples are welcome on the wiki or mailing list. These references may be helpful: https://dev.mysql.com/doc/refman/8.0/en/create-user.html and https://dev.mysql.com/doc/refman/8.0/en/grant.html. Creating a Role/User -------------------- The following command will create a ``roundupuser`` with the ability to create the database:: mysql -u root -e 'CREATE USER "roundupuser"@"localhost" IDENTIFIED WITH mysql_native_password BY "rounduppw"; GRANT ALL on roundupuser.* TO "roundupuser"@"localhost";' Other Configuration =================== If you are indexing large documents (e.g attached file contents) using MySQL, you may need to increase the max_allowed_packet size. If you don't you can see the error:: 'MySql Server has gone away (2006)' To do this edit /etc/my.conf and change:: [mysqld] max_allowed_packet = 1M the 'max_allowed_packet' value from '1M' to '64M' or larger. Alternatively you can install an alternate indexer (whoosh, xapian etc.) and force the tracker to use it by setting the ``indexer`` setting in the tracker's ``config.ini``. This fix was supplied by telsch. See issue https://issues.roundup-tracker.org/issue2550743 for further info or if you are interested in developing a patch to roundup to help work around this issue. Running the MySQL tests ======================= Roundup tests expect an empty MySQL database. Two alternate ways to provide this: 1. If you have root permissions on the MySQL server, you can create the necessary database entries using the following SQL sequence. Use ``mysql`` on the command line to enter:: CREATE DATABASE rounduptest; USE rounduptest; GRANT ALL PRIVILEGES ON rounduptest.* TO rounduptest@localhost IDENTIFIED BY 'rounduptest'; FLUSH PRIVILEGES; 2. If your administrator has provided you with database connection info, see the config values in 'test/db_test_base.py' about which database connection, name and user will be used. The MySQL database should not contain any tables. Tests will not drop the database with existing data. Note that ``rounduptest`` is a well known account. You should delete it and the ``rounduptest`` database and create a new user/database for production use. Showing MySQL who's boss ======================== If things ever get to the point where that test database is totally hosed, just:: $ su - # /etc/init.d/mysql stop # rm -rf /var/lib/mysql/rounduptest # /etc/init.d/mysql start and all will be better (note that on some systems, ``mysql`` is spelt ``mysqld``).
