tballison commented on code in PR #3179:
URL: https://github.com/apache/tika/pull/3179#discussion_r4025045789
##########
docs/modules/ROOT/pages/using-tika/server/index.adoc:
##########
@@ -154,6 +154,39 @@ not (detectors, embedded-document extraction, exception
reporting, ...) and rais
limits above the per-request clamp. Every active preset resolves at startup,
so a bad preset
fails the server, not its first request.
+WARNING: An active preset is a public route: anyone who can reach the server
can call it, and
+it runs at config trust — it can bind components `/config` cannot and raise
timeout limits
+above the per-request clamp. Vet a preset as you would
`allowPerRequestConfig`, scoped to what
+the preset turns on. Tika's catalog presets are kept bounded (page and render
caps, no OCR
+unless the preset is about OCR, no timeout raises); hold your own to the same
bar. Startup
+logs one line per active preset naming the components it configures.
+
+==== The `thumbnails` catalog preset
+
+Tika ships one catalog preset, `thumbnails` (in `tika-pipes-core`), for
+`/unpack/preset/thumbnails`. Nothing is active until the operator names it:
+
+[source,json]
+----
+{ "presets": { "thumbnails": true } }
Review Comment:
We should talk about this. I'm really worried about presets going
automatically "live" by default. These two are good, but going forward, we have
to ensure that devs will not add a default that is dangerous in some
environment.
The current PR defines presents, but the operator still has to turn them on.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
