Tim, both methods complicate automated tika-server usage (e.g. as service) since they require user interaction when starting server (or parsing stdout to share that uuid with downstream services).
Do we really want to bring full-fledged security layer in tika-server with something like api keys? I'm not familar with CXF, so might overestimate diffuculty of adding such layer. My implicit assumption was that tika-server is mostly solution to quick start, easy evaluation and quick&dirty service for light load, not a service which you expose on external server port ever. From this perspective we at least should prevent user from making unintentional security hole for which two flags may be sufficient. Of course, I could be wrong and some of our users may use it exposed to the wild Internet/dmz/intranet. But such usage allows malice user to make DoS attack with ease. ср, 14 сент. 2016 г. в 18:51, Allison, Timothy B. <talli...@mitre.org>: > Should we require that the user enter a key, or have tika-server spit out > a random UUID that clients have to include in their calls? > > Or will Konstantin's two flags be sufficient? > -- Best regards, Konstantin Gribov
