refactor: consolidate audit-log code into dojo/auditlog/ package

[Maffooch]

Summary

• Moves dojo/auditlog.py (1,083 lines), dojo/pghistory_models.py, and dojo/pghistory_utils.py into a self-contained dojo/auditlog/ package that mirrors the dojo/url/ canonical layout from CLAUDE.md.
• Also pulls the audit-log view (action_history), its template, and LogEntryFilter/PgHistoryFilter into the package — they previously lived in dojo/views.py, dojo/templates/, and dojo/filters.py.
• New dojo/auditlog/settings.py becomes the source of truth for the audit-log env-var schema and pghistory field defaults; settings.dist.py imports from it.
• Backward-compatible re-exports stay at the original locations per the playbook, so the 21 existing call sites keep working without churn.

Layout

dojo/auditlog/
├── __init__.py        # PEP 562 lazy re-exports
├── models.py          # DojoEvents (app_label auto-inferred to "dojo")
├── services.py        # registration + cleanup + config
├── helpers.py         # display formatting + Celery context wrappers
├── backfill.py        # backfill subsystem
├── filters.py         # LogEntryFilter, PgHistoryFilter
├── settings.py        # env schema + pghistory field defaults
├── ui/
│   ├── __init__.py
│   ├── views.py       # action_history
│   └── urls.py        # action_history route
└── templates/dojo/action_history.html

Notable details

• __init__.py uses PEP 562 lazy attribute resolution. settings.dist.py imports dojo.auditlog.settings at Django settings-load time, before django.conf.settings is built; eager re-exports would circularly pull in django-dependent submodules.
• DojoEvents drops the explicit app_label = "dojo" per CLAUDE.md ("DO NOT set app_label in Meta — auto-inferred"). makemigrations --check reports zero new migrations.
• Defensive try/except blocks in services and backfill are intentionally dropped — let pgtrigger / COPY failures surface loudly rather than silently swallowing them.
• dojo/settings/settings.dist.py becomes a consumer of dojo.auditlog.settings: imports the env-schema dict (splatted into environ.Env via **AUDITLOG_ENV_SCHEMA), the three PGHISTORY_*_FIELD constants, and AUDITLOG_DISABLE_ON_RAW_SAVE; adds dojo/auditlog/templates to TEMPLATES[0][\"DIRS\"] since dojo.auditlog isn't a separate Django app.
• unittests/test_auditlog.py: two @patch targets updated from dojo.auditlog.call_command to dojo.auditlog.services.call_command, reflecting where the import now lives.

Out of scope (deferred per playbook)

• Updating the 21 stub-using call sites (apps.py, tasks.py, signals, management commands, migrations, two test files) to import from new paths — explicitly a separate cleanup pass.
• Moving per-domain audit-log signal handlers (dojo/test/signals.py etc.) into dojo/auditlog/signals.py — they're domain-coupled by design.
• Removing the legacy django-auditlog library; LogEntryFilter still references it for the page's "legacy entries" pane.

Test plan

• python manage.py check — no issues
• python manage.py makemigrations --check — No changes detected (the critical migration gate)
• unittests.test_auditlog — 7/7 pass
• unittests.test_importers_performance — 10/10 pass
• reverse('action_history', cid=1, oid=2) — resolves to /history/1/2 (route name preserved)
• End-to-end: edit a Finding in the UI; visit /history/<cid>/<oid>; confirm template renders, filters work (event type, user, IP, diff search), and a pghistory event is recorded with user/url/remote_addr/source/scan_type context fields populated.

🤖 Generated with Claude Code

[valentijnscholten]

Defensive try/except blocks in services and backfill are intentionally dropped — let pgtrigger / COPY failures surface loudly rather than silently swallowing them.

Why are these being dropped? In case of some unexpected error this would block users from starting their instances after an upgrade.

[Maffooch]

I went back and looked at each spot to make sure the upgrade path wouldn't blow up, and I think we are actually safe here. For configure_pghistory_triggers has the same try/catch that was just an error log then a raise. The exception already propagated, so removing the wrapper only loses the friendlier log line ahead of the traceback, but the startup blocking behavior is identical.

For the outer try/catch around process_model_backfill, the only callers on the upgrade path are the backfill migrations, and both already wrap the call in their own try/catch. A backfill failure during migration wont abort the migration or block startup after an upgrade.

The one real behavior change is in the manual pghistory_backfill_fast. it now exits on model failure instead of silently moving on. If you'd like the friendlier log message ahead of the traceback, happy to add the error log back and let it continue if there was an error

[dryrunsecurity]

This pull request contains a high-severity SQL injection risk in dojo/auditlog/backfill.py, where multiple queries and a COPY statement are built with f-string interpolation of table names and SQL fragments. Although the values currently come from internal mappings, the raw SQL pattern could become exploitable if any of those inputs are ever influenced by attacker-controlled data.

🟠 Potential SQL Injection in dojo/auditlog/backfill.py (drs_6ece4114)

Vulnerability

Potential SQL Injection

Description

The code uses raw SQL execution with dynamically formatted table names and SQL fragments via cursor.execute(f"SELECT COUNT(*) FROM {table_name}"), cursor.execute(f"SELECT COUNT(*) FROM {event_table_name} ..."), cursor.execute(f"SELECT t.id FROM {table_name} t ..."), and copy_sql = f"COPY {event_table_name} (...) ...". Even though the table names come from internal mappings rather than direct request input, this is still raw SQL built via string interpolation, which is the kind of pattern that can lead to SQL injection if any of those values become attacker-controlled or are modified unsafely.

django-DefectDojo/dojo/auditlog/backfill.py

Lines 173 to 176 in 0fbdf08

	cursor.execute(f"SELECT COUNT(*) FROM {table_name}")
	total_count = cursor.fetchone()[0]
	if total_count == 0:

---

Comment to provide feedback on these findings.

Report false positive: @dryrunsecurity fp [FINDING ID] [FEEDBACK]
Report low-impact: @dryrunsecurity nit [FINDING ID] [FEEDBACK]

Example: @dryrunsecurity fp drs_90eda195 This code is not user-facing

All finding details can be found in the DryRun Security Dashboard.

[valentijnscholten]

I went back and looked at each spot to make sure the upgrade path wouldn't blow up, and I think we are actually safe here. For configure_pghistory_triggers has the same try/catch that was just an error log then a raise. The exception already propagated, so removing the wrapper only loses the friendlier log line ahead of the traceback, but the startup blocking behavior is identical.

For the outer try/catch around process_model_backfill, the only callers on the upgrade path are the backfill migrations, and both already wrap the call in their own try/catch. A backfill failure during migration wont abort the migration or block startup after an upgrade.

The one real behavior change is in the manual pghistory_backfill_fast. it now exits on model failure instead of silently moving on. If you'd like the friendlier log message ahead of the traceback, happy to add the error log back and let it continue if there was an error

ok sounds like it is ok as-is

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[mtesauro]

Approved

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.