Thanks. Raised as TIKA-2081 (currently unassigned). -----Original Message----- From: Allison, Timothy B. [mailto:talli...@mitre.org] Sent: 16 September 2016 11:22 To: dev@tika.apache.org; jle...@lightblue.com Subject: RE: Query on correct use of 'fileUrl' in TikaJAXRS Server to extract document at remote url - my request is not working
I may have time to do this. I would definitely have time to review a patch ;). Please open a ticket on our Jira. -----Original Message----- From: John Dougrez-Lewis [mailto:jle...@lightblue.com] Sent: Friday, September 16, 2016 1:39 AM To: dev@tika.apache.org Subject: RE: Query on correct use of 'fileUrl' in TikaJAXRS Server to extract document at remote url - my request is not working Ok, subject to the two security safeguards discussed, if people are ok with this, please can the 'fileUrl' functionality be schedules to be added back in the next release ? -----Original Message----- From: Allison, Timothy B. [mailto:talli...@mitre.org] Sent: 14 September 2016 17:55 To: dev@tika.apache.org Subject: RE: Query on correct use of 'fileUrl' in TikaJAXRS Server to extract document at remote url - my request is not working Makes sense. I agree; I don't want a full fledged security layer. -----Original Message----- From: Konstantin Gribov [mailto:gros...@gmail.com] Sent: Wednesday, September 14, 2016 12:51 PM To: dev@tika.apache.org Cc: jle...@lightblue.com Subject: Re: Query on correct use of 'fileUrl' in TikaJAXRS Server to extract document at remote url - my request is not working 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
