Skip to content

Use a shared JDOM builder for bookmark and configuration parsing - #173

Open
snoopdave wants to merge 2 commits into
masterfrom
shared-jdom-builder
Open

Use a shared JDOM builder for bookmark and configuration parsing#173
snoopdave wants to merge 2 commits into
masterfrom
shared-jdom-builder

Conversation

@snoopdave

Copy link
Copy Markdown
Contributor

Several call sites each construct their own JDOM SAXBuilder, with inconsistent
parser settings. This change consolidates them behind one shared,
consistently-configured builder.

What changed

  • Add SafeSAXBuilder (extends SAXBuilder) configured with secure processing
    enabled, document type declarations disallowed, external entity and external
    DTD resolution disabled, and entity expansion disabled.
  • Apply it at the OPML bookmark import and the retained internal parsers
    (MenuHelper, RuntimeConfigDefsParser, ThemeMetadataParser).
  • Leave Trackback.java untouched; that file is removed separately.

Note for the release notes: OPML documents carrying a DOCTYPE are now rejected
and will no longer import. OPML does not require a DOCTYPE.

Tests

SafeSAXBuilderTest asserts the parser contract directly, and
BookmarkImportParsingTest exercises it through the import path, including that
ordinary OPML still imports and that documents with external entities store no
entity content.

An XML document can name resources for the parser to fetch: a document type
declaration can point at an external subset, and entity declarations can point
at files or URLs. Resolving those makes the parser act for whoever wrote the
document, which suits Roller's own descriptors and not documents it parses from
user input.

SafeSAXBuilder settles that once for every retained JDOM parser rather than per
call site: the document type declaration is refused, external entity and DTD
resolution is switched off, and entity expansion is disabled. The OPML bookmark
import, the menu parser, the runtime config parser and the theme metadata
parser all build through it. Roller's own descriptors carry no document type
declaration, so nothing about how they parse changes.

The two JAXP access properties are applied through the reader factory and
tolerated when unrecognised, because the Xerces Roller ships rejects them at the
SAX layer; the parser features are what carry the behaviour.

Trackback.java is deliberately left alone.

Claude-Session: https://claude.ai/code/session_01A1fhY1E2PCFU6UAPXu2WtV
Move the resource-resolution demonstrations out of the committed suite. The
retained tests verify that ordinary documents still parse and that any document
type declaration is refused.

Claude-Session: https://claude.ai/code/session_01A1fhY1E2PCFU6UAPXu2WtV
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant