[ 
https://issues.apache.org/jira/browse/TIKA-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15515073#comment-15515073
 ] 

Tim Allison commented on TIKA-1627:
-----------------------------------

We removed fileUrl in Tika 1.10 because it was a [security 
vulnerability|https://mail-archives.apache.org/mod_mbox/tika-user/201508.mbox/%3cb7848c4e-bc38-4477-832e-b1138b831...@apache.org%3E].
  We're about to add it back with warnings to users and with the requirement 
via commandline opts that the user acknowledges the risks.

> Authentication for fileUrl
> --------------------------
>
>                 Key: TIKA-1627
>                 URL: https://issues.apache.org/jira/browse/TIKA-1627
>             Project: Tika
>          Issue Type: Improvement
>          Components: server
>    Affects Versions: 1.9
>            Reporter: Jamshid Afshar
>
> The fileUrl feature in 1.9-SNAPSHOT is great! Are there plans for letting the 
> client provide auth credentials for the request to the remote source 
> (fileUrl)? Seems tika would need support for HTTP Basic/Digest 
> username:password, then HTTPS certificates, and maybe AWS S3 access+secret 
> keys. But, I guess S3 auth can be used now if the client provides a signed 
> url.
> I tried the (old and deprecated?) HTTP url syntax containing 
> username:password, but that is apparently ignored. Tika gets a 401 and that 
> causes tika to respond with a 500 error.
> {noformat}
> $ curl -H "fileUrl: http://user:passw...@example.com/foo.jpg"; -H "Accept: 
> application/json" -X PUT http://localhost:9998/meta
> HTTP/1.1 500 Server Error
> {noformat}
> I think it's fine to require credentials to be provided in each request, but 
> others might want them configurable on the server, probably by domain or 
> domain + path.
> A weird alternative solution to this might be for tika to be like a proxy -- 
> pass through any Authorization: or Cookie: from the request and forward any 
> 401/403 response from the remote source (fileUrl) to the tika client. I 
> wonder if that might make an OAuth handler for the remote source 
> possible/easier.
> Sorry if this isn't the right place to suggest this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to