Skip to content

fix: take only module-level TEMPLATES as Django settings - #186

Merged
SizzleUnrlsd merged 2 commits into
mainfrom
fix/request-processor-scope
Sep 29, 2026
Merged

SizzleUnrlsd merged 2 commits into
mainfrom
fix/request-processor-scope

Conversation

@SizzleUnrlsd

Copy link
Copy Markdown
Contributor

Closes #184.

Summary

  • request_processor walked every node of every module and counted any TEMPLATES = […] as Django settings, so an assignment inside a function, called or not, or a class attribute activated the request context processor and upgraded a template filter finding to exploitable.
  • It now walks each module with its scope table (ScopeAnalysis, already computed): an assignment counts only at module scope, and a mention counts only when the name resolves to the module's binding, or to nothing, which a star import gives. A function-local TEMPLATES is another name: it neither activates nor invalidates. A function that reads, mutates or rebinds (global) the module's TEMPLATES still leaves the activation uncertain, as before.
  • ScopeTable.scope_for now accepts a lambda, whose scope the builder already recorded; the walk needs it to enter every scope the builder knows.
  • Documented in the usage guide and the changelog.

Verification

  • RED: three failures for the expected reasons: a function-local and a class-level TEMPLATES activated the processor, and a local TEMPLATES beside module settings disabled it.
  • tests/test_settings_scope.py: 9 passed; the request-processor and docs tests pass. Full suite (regression excluded in the worktree): all passed. ruff check and mypy pass.
  • Mutations: removing the scope check fails the local-name test; ignoring unbound names fails the star-import test.

…ocessor

A TEMPLATES bound in a function, called or not, or in a class configures nothing; a function reading, mutating or rebinding the module's TEMPLATES leaves the activation uncertain; a local TEMPLATES beside module settings changes nothing.
request_processor walked every node of every module and counted any assignment to TEMPLATES, so a function-local or class-level assignment activated the request context processor. It now walks the modules with their scope tables: an assignment counts only at module scope, and a mention counts only when the name resolves to the module's binding, or to nothing, as a star import gives. ScopeTable.scope_for accepts a lambda, whose scope the builder already records.
@SizzleUnrlsd SizzleUnrlsd added the bug Something isn't working label Sep 28, 2026
@SizzleUnrlsd SizzleUnrlsd self-assigned this Sep 28, 2026
@SizzleUnrlsd
SizzleUnrlsd merged commit 85508e3 into main Sep 29, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[P2] Do not infer an active Django request processor from function-local settings

1 participant