Serve AtomPub through a Roller servlet

[snoopdave]

Summary

Maps /roller-services/app/* to a new RollerAtomServlet, a small subclass of Propono's AtomServlet, so Roller controls how AtomPub requests are handled before Propono sees them.

• Honour webservices.enableAtomPub on every request. Until now only the service document checked the setting. With AtomPub off, the endpoint now answers 404, the same way the XML-RPC endpoint does.
• Read Atom entry bodies with Roller's standard XML parser configuration. For a POST of Atom content or a PUT to an entry URI, the servlet reads the body (up to 10 MB), parses it with the same SafeSAXBuilder settings Roller uses elsewhere, and hands Propono a buffered copy. An entry that does not parse gets 400; an oversized one gets 413. Media uploads and reads are unchanged.
• RollerAtomHandler's entry-URI rule moves into a static isEntryPath helper, so the servlet and the handler use the same test.

Testing

• New RollerAtomServletTest (10 tests): disabled service, pass-through of reads and media, buffered forwarding of a normal entry, refused entries on POST and PUT, size limit, and the shared entry-path rule.
• mvn -pl app test on JDK 11: 335 tests, 0 failures, 1 skipped.

Targets roller-6.1.x for 6.1.7. It will be cherry-picked to master after the 6.1.7 release.

[snoopdave]

PR-Review: 1 inline comment posted.

[snoopdave]

🐞Claude Issue: PR-Review: General Issues

The following issues were found but cannot be attached to a specific line in the diff:

• Blocking: CHANGES.md on roller-6.1.x is not updated. Add a short 6.1.7 entry: AtomPub now honours webservices.enableAtomPub on every request (404 when off), and entry bodies have a 10 MB limit (413 when larger).
• Important: No CI runs on this PR. On roller-6.1.x, main.yml and codeql-analysis.yml trigger only for master, so nothing on the branch is checked automatically. I ran RollerAtomServletTest locally on JDK 11: 10 tests, 0 failures. Consider adding roller-6.1.x to the workflow triggers on that branch before the 6.1.7 PRs merge.

[snoopdave]

🤖Claude:

• CHANGES.md: fixed by adding a 6.1.7 section with both behaviour changes: every AtomPub URL answers 404 while webservices.enableAtomPub is off, and entry bodies over 10 MB get 413 (not yet pushed).
• CI: not fixed here. Run CI and CodeQL on roller-6.1.x #206 has since added roller-6.1.x to the CI and CodeQL triggers. This PR predates that change, so checks will start after it is rebased onto roller-6.1.x.

[snoopdave]

With those fixes, I think this PR is ready for merge.

[snoopdave]

Manually tested on the 6.1.7 integration build (Tomcat 9, JDK 11, MySQL 8) with curl and basic auth. Pass.

• With AtomPub on:
  • The service document, entry POST (201) and PUT (200), the entries feed, and media POST with Slug work.
  • A malformed entry, or one with an external entity or DTD, returns 400 for both POST and PUT. Nothing is fetched.
  • An 11 MB entry returns 413.
  • With no credentials or a wrong password, the response is 401, even for malformed or oversized bodies. So authentication runs before the body is read.
• With AtomPub off, every URL returns 404 at once, with no restart.

Testing found some old MediaCollection bugs that this PR did not cause, such as listing /resources/default. They are fixed in #207.

[ppkarwasz]

You already have commons-io as a transitive dependency. You could use it to replace readBody:

Suggested change

	byte[] body = readBody(req.getInputStream());
	if (body == null) {
	sendText(res, HttpServletResponse.SC_REQUEST_ENTITY_TOO_LARGE, "Entry is too large");
	return;
	}
	// Read one byte past the limit, so an oversized body can be detected.
	byte[] body = IOUtils.toByteArray(
	BoundedInputStream.builder()
	.setInputStream(req.getInputStream())
	.setMaxCount(MAX_ENTRY_BYTES + 1L)
	.get());
	if (body.length > MAX_ENTRY_BYTES) {
	sendText(res, HttpServletResponse.SC_REQUEST_ENTITY_TOO_LARGE, "Entry is too large");
	return;
	}

In Java 9+ you also have InputStream.readNBytes()

[ppkarwasz]

JDOM builds a tree that is later discarded. You might use a SAXParser instead with an empty content handler. The following code uses Commons Secure XML 1.1.0 (which will be released today) to validate the stream:

        try {
            DefaultHandler2 doctypeRefuser = new DefaultHandler2() {
                @Override
                public void startDTD(String name, String publicId, String systemId)
                        throws SAXException {
                    throw new SAXException("DOCTYPE is not allowed in an Atom entry");
                }
            };
            SAXParser parser = SecureSAXParserFactory.newNSSAXParser();
            parser.setProperty("http://xml.org/sax/properties/lexical-handler", doctypeRefuser);
            parser.parse(new InputSource(new InputStreamReader(
                    new ByteArrayInputStream(body), StandardCharsets.UTF_8)), doctypeRefuser);
        } catch (SAXException e) {
            LOG.debug("Rejecting Atom entry that could not be parsed", e);
            sendText(res, HttpServletResponse.SC_BAD_REQUEST, "Invalid Atom entry");
            return;
        }

[ppkarwasz]

Isn't this limit a little high form one Atom entry? The entry still need to fit in the database. Even counting for the overhead of XML, 128 KiB or 1 MiB should be enough for all users.

This value might also be configurable (webservices.atomPubMaxEntrySize?).