Skip to content

Anon ticket

A web application that allows users to create anonymous tickets on the Tor Project's GitLab instance by leveraging the GitLab API.

The project is developed in-house and hosted on GitLab at tpo/tpa/anon_ticket.

Tutorial

How-to

Creating access tokens

The access tokens detailed in the Authentication section were created as follows:

  1. create a normal service account called anonticket, then an access token for it called GITLAB_SECRET_TOKEN. this one is to create and respond to issues. it only has api permissions.
  2. create a separate service account called anonticket-admin. this one will have privileges to manage users.
  3. then go in the user list, find anonticket-admin again, edit the user, and mark it as admin
  4. go back to the service account listing, find anonticket-admin again, and create a new access token named anonticket-admin, which has api and admin mode privileges.

Those two tokens should be added to the anon_ticket .env file, as per the README file, steps 5 and 6, which currently read:

  1. Set GITLAB_SECRET_TOKEN as your Tor GitLab account token.
  2. If you have the ability to make user accounts, you can set the GITLAB_ACCOUNTS_SECRET_TOKEN variable.

Step 5 is the first token above (GITLAB_SECRET_TOKEN), step 6 (GITLAB_ACCOUNTS_SECRET_TOKEN) is the admin token.

See also more in-depth documentation about authentication here.

Renewing access tokens

The access tokens detailed in the Authentication section can be rotated as follows:

  1. find the anonticket service account
  2. find the access token with the api access level
  3. click "rotate" in the "three dots" menu. if you need to change permissions, you'll need to revoke this one and create a new one
  4. same for the anonticket-admin service account, but on the access token with the admin_mode, api access level

See Creating access tokens for where to put those tokens.

Pager playbook

Disaster recovery

If the PostgreSQL database isn't lost, see the installation procedure.

If having to install from scratch, see also anon_ticket Quickstart

Reference

Installation

Prerequisite for installing this service is an LDAP role account.

The service is mainly deployed via the profile::anonticket Puppet class, which takes care of installing dependencies, configuring a postgresql user/database, an nginx reverse proxy and systemd user service unit file.

A Python virtual environment must then be manually provisioned in $HOME/.env, and the ticketlobby.service user service unit file must then be enabled and activated.

Upgrades

$ source .env/bin/activate # To activate the python virtual environment $ cd anon_ticket $ git fetch origin main $ git merge origin/main $ python manage.py migrate # To apply new migrations $ python manage.py collectstatic # To generate new static files $ systemctl --user reload/restart ticketlobby.service

SLA

There is no SLA established for this service.

Design and architecture

anon_ticket is a Django application and project. Frontend is served by gunicorn and nginx as proxy and nginx for static files. It uses TPA's postgresql for storage and Gitlab API to create users, issues and notes on issues.

Services

The nginx reverse proxy listens on the standard HTTP and HTTPS ports, handles TLS termination, and forwards requests to the ticketlobby service unit that launches gunicorn, which handles the anon_ticket Django project (call ticketlobby) containing the application WSGI.

Storage

Persistent data is stored in a PostgreSQL database.

Queues

None.

Interfaces

This service uses the Gitlab REST API.

The application can be managed via its Web interface or via Django cli

Authentication

The service authenticate with two different access tokens:

  • a normal access token for creating issues and comments, named GITLAB_SECRET_TOKEN created from a service account named anonticket
  • an admin access token for creating users, named anonticket-admin from a service account named anonticket-admin, which corresponds to the app's GITLAB_ACCOUNTS_SECRET_TOKEN

This was originally split between the lobby account (now renamed juga-admin, used to create the anonticket-admin account) and a cypherpunks account (now named anonticket) in tpo/tpa/team#41510, then modified in tpo/tpa/anon_ticket#131.

Note that we'll eventually want to reduce the scope of those tokens, particularly the admin token, see tpo/tpa/team#42698.

Also note that admin mode has effect only if Admin mode is enabled. But don't get confused: if Admin mode is disabled in the GitLab administration panel, the admin mode flag on an API token has no effect, and that means the token inherits the admin privileges of the user, not that the token acts as a regular user! The user is still admin!

Finally, we use service accounts here because we don't want to manage a real user for those tokens. A service account doesn't count towards seats, doesn't need to have an email, and generally looks like a bot which, really, this is what this service is: an automated bridge into GitLab. This could have been done with real user accounts, but it's more confusing.

Implementation

Python, Django >= 3.1 licensed under BSD 3-Clause "New" or "Revised" license.

Gitlab, PostgreSQL, nginx

Issues

This project has its own issue tracker at https://gitlab.torproject.org/tpo/tpa/anon_ticket/-/issues

Maintainer

Service deployed by @lavamind, @juga and @ahf.

Users

Any user that wish to report/comment an issue in https://gitlab.torproject.org, without having an account.

Upstream

Upstream are volunteers and some TPI persons, see Contributor analytics

Upstream is not very active.

To report Issues, see Issues.

Monitoring and metrics

No known monitoring nor metrics.

To keep up to date, see Upgrades.

Tests

The service has to be tested manually, going to https://anonticket.torproject.org and check that you can:

  • create identifier
  • login with identifier

    • See a list of all projects
    • Search for an issue
    • Create an issue
    • Create a note on an existing issue
    • See My Landing Page
    • request gitlab account

To test the code, see anon_ticket Tests

Logs

Logs are sent to journal. Gunicorn access and error logs are also saved at $HOME/log without IP (proxy's one) nor User-Agent.

Backups

Other documentation

anon_ticket README

Discussion

This service was initially deployed by @ahf at https://anonticket.onionize.space/ and has been migrated here, see tpo/tpa/team#40577.

In the long term, this service will deprecate https://gitlab.onionize.space/ service, deployed by @ahf, from the Gitlab Lobby code, because its functionality has already been integrated in anon_ticket.

Overview

Security and risk assessment

Technical debt and next steps

Nothing urgent.

Next steps: anon_ticket Issues

Proposed Solution

Other alternatives