view doc/tracker_templates.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 3614cd64f4c4
children
line wrap: on
line source

=========================
Roundup Tracker Templates
=========================

The templates distributed with Roundup are stored in the "share" directory
nominated by Python. On Unix this is typically
``/usr/share/roundup/templates/`` (or ``/usr/local/share...``) and
on Windows this is ``c:\python38\share\roundup\templates\``.

The template loading looks in four places to find the templates:

1. *share* - eg. ``<prefix>/share/roundup/templates/*``.
   This should be the standard place to find them when Roundup is
   installed running setup.py from source.
2. ``install_dir``/../<prefix>/share/....``, where prefix is the
   Python's ``sys.prefix``. ``sys.base_prefix`` or 
   `sys.base_prefix/local``. This finds templates (and locales)
   installed by pip. E.G. in a virtualenv located at (``sys.prefix``):
   ``/tools/roundup``, roundup would be at:
   ``/tools/roundup/lib/python3.7/site-packages/roundup``. The
   templates would be at:
   ``/tools/roundup/lib/python3.7/site-packages/tools/roundup/share/roundup/templates/``. (Replace 3.7 with the Python version you are running.)
3. ``<roundup.admin.__file__>/../../share/roundup/templates/*``.
   This will be used if Roundup's run in the distro (aka. source)
   directory.
4. ``<current working dir>/*``.
   This is for when someone unpacks a 3rd-party template.
5. ``<current working dir>``.
   This is for someone who "cd"s to the 3rd-party template dir.

Templates contain:

- modules ``schema.py`` and ``initial_data.py``
- directories ``html``, ``detectors`` and ``extensions``
  (with appropriate contents)
- optional directory ``lib`` which contains modules used by the other
  tracker components
- optional ``config_ini.ini`` file. It is structured like a tracker's
  ``config.ini`` but contains only headers (e.g. ``[main]``) and
  *required* parameters that are different from defaults. For example::
  
    [main]
    template_engine = jinja2

    static_files = static

  These settings override the default values in the tracker's
  ``config.ini`` when using roundup-admin to install a template.
- template "marker" file ``TEMPLATE-INFO.txt``, which contains
  the name of the template, a description of the template
  and its intended audience.

  An example TEMPLATE-INFO.txt:

  .. code-block:: text

     Name: classic
     Description: This is a generic issue tracker that may be used to
		  track bugs, feature requests, project issues or any
		  number of other types of issues. Most users of
		  Roundup will find that this template suits them,
		  with perhaps a few customisations.
     Intended-For: All first-time Roundup users


Roundup Issue Tracker: http://roundup-tracker.org/