* Fix customer views using wrong csrf middleware
This lead to persistent csrf validation errors if the token from the cookie expired, which could only be solved by clearing cookies.
* Remove unneccesary csrf_protect decorators
* Fix typo
Co-authored-by: Raphael Michel <michel@pretix.eu>
---------
Co-authored-by: Raphael Michel <michel@pretix.eu>
As a security precaution, we change the contract of some signals such that a
SafeString needs to be returned if HTML should be rendered without further
escaping.
Before, the `{% signal ... %}` and `{% eventsignal ... %}` template tags
called mark_safe themselves on all strings returned from signals. That could
lead to unsafe coding practices, where untrusted values are interpolated into
HTML format strings. However, such interpolations should usually be performed
using helpers such Django's format_html, which automatically escapes inputs
and returns a SafeString.
Now, we call conditional_escape on signal results, so that any HTML not explicitly
marked as safe gets escaped.
Most plugins are not affected by this change as they return a SafeString as a
result of Template.render already.
* Drop nullability on Order.organizer and OrderPosition.organizer
* Rebase migration and add autoclean
* Utilize new relationship for scopes
* Declare reverse noop
* Update src/pretix/base/migrations/0302_resolve_duplicate_codes_and_secrets.py
Co-authored-by: Martin Gross <gross@rami.io>
* Update src/pretix/base/migrations/0302_resolve_duplicate_codes_and_secrets.py
Co-authored-by: Martin Gross <gross@rami.io>
---------
Co-authored-by: Martin Gross <gross@rami.io>
* Add trace IDs from request to celery task
Celery tasks will log the request ID they were triggered from:
[2026-07-02 10:33:17,614: INFO/MainProcess] Task pretix.base.services.orders.cancel_order[5f3104b3-0a54-4e49-921e-c866c4dc4c6d] received
[2026-07-02 10:33:17,614: INFO/MainProcess] Task 5f3104b3-0a54-4e49-921e-c866c4dc4c6d has trace 4d389638-00ab-4c4d-bdec-d73ac322bf44
Nested celery tasks will then contain both the request ID as well as the previous tasks:
[2026-07-02 10:33:18,354: INFO/MainProcess] Task pretix.base.services.notifications.notify[d52a3a49-9c89-4f67-bdde-9f773586fc07] received
[2026-07-02 10:33:18,354: INFO/MainProcess] Task d52a3a49-9c89-4f67-bdde-9f773586fc07 has trace 4d389638-00ab-4c4d-bdec-d73ac322bf44 5f3104b3-0a54-4e49-921e-c866c4dc4c6d
* Apply suggestion from @luelista
Co-authored-by: luelista <weller@rami.io>
---------
Co-authored-by: luelista <weller@rami.io>
This is a follow-up for #6318, basically the same problem but in a
neighboring query.
Performance comparison for real-world event with 13k subevents:
In [15]: %time get_grouped_items(e, subevent=se, channel=e.organizer.sales_channels.get(identifier="web"))
CPU times: user 49.1 ms, sys: 3.79 ms, total: 52.9 ms
Wall time: 1.12 s
Out[15]: ([<Item: xxx>], True
In [16]: %time get_grouped_items_patched(e, subevent=se, channel=e.organizer.sales_channels.get(identifier="web"))
CPU times: user 30.2 ms, sys: 445 μs, total: 30.6 ms
Wall time: 45.3 ms
Out[16]: ([<Item: xxx>], True)
During our [2026-06-27 incident](https://pretix.eu/about/en/blog/20260630-pretix-hosted-outage/),
we noticed that pretix is using redis at import time. This means that
gunicorn and celery process were unable to start on servers who could
currently not reach redis. This is kinda mitigated through auto-restart
on systemd or docker level, but that's not really how it is supposed to
work. Celery even has smart retry/reconnect logic that becomes pointless
this way.
Raphael Michel