[
https://issues.apache.org/jira/browse/JENA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697260#comment-13697260
]
Rob Vesse commented on JENA-480:
--------------------------------
Now that Andy has reworked DatasetAccessorGraphHTTP to go through HttpOp (with
the requisite additional refactoring there) I have gone ahead and updated
DatasetAccessorGraphHTTP to allow configuring an authenticator. I added an
additional createHTTP() overload to DatasetAccessorFactory that includes a
HttpAuthenticator parameter.
I also reworked scoped authenticators today so all scoped implementations
derived from AbstractScopedAuthenticator. Part of this refactoring was to have
a common pattern for how scoping happens so now credentials are consistently
scoped to all URIs derived from them. For example if we have credentials
registered for http://example.org these will also be applied to
http://example.org/some/path where previously they wouldn't.
Longest match applies since we start from the full request URI and reduce it
down as far as possible, this means you can still specify different credentials
for different areas of a site and the authenticators will pick the most
appropriate.
I have also added a DelegatingAuthenticator which is designed to make it easy
to mix and max different authentication mechanisms by having a single
authenticator which delegates to specific implementations depending on the URI
we are trying to authenticate against.
> Unify HTTP usage and authentication mechanisms in ARQ
> -----------------------------------------------------
>
> Key: JENA-480
> URL: https://issues.apache.org/jira/browse/JENA-480
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
> Reporter: Rob Vesse
> Assignee: Rob Vesse
> Fix For: Jena 2.10.2
>
> Original Estimate: 72h
> Time Spent: 5h
> Remaining Estimate: 67h
>
> Currently ARQ uses a mixture of HttpClient and HttpURLConnection to perform
> various HTTP operations e.g. SPARQL Queries, SPARQL Updates and SPARQL Graph
> Store Protocol.
> This has the effect of making the code somewhat awkward to maintain and makes
> certain operations like authentication more complex than they need to be
> because different parts of the system support different modes of
> authentication.
> For example currently SPARQL queries only support Basic Auth and they always
> pre-authenticate so they cannot do proxy auth or use any other kind of auth
> method. On the other hand SPARQL updates use HttpClient which is capable of
> performing Basic, Digest, NTLM, SPNEGO and Kerberos for both normal and proxy
> auth but is never pre-authenticates.
> This task proposes unifying all HTTP operations in ARQ to use Apache
> HttpClient since it is more flexible and introducing a more extensible
> framework for doing authentication.
> In terms of HTTP unification we need to convert the following:
> - HttpQuery should use HttpClient
> - LocatorURL should use HttpClient
> In terms of HTTP Authentication my idea is as follows, introduce a new
> interface HttpAuthenticator which provides an apply(AbstractHttpClient
> client, URI target) method. All systems that may permit HTTP auth will allow
> use of an authenticator, providing a generic interface for authenticators
> will allow us to introduce authenticators for other auth schemes e.g. form
> based logins.
> We can also provide authenticators that leverage existing mechanisms e.g.
> storing credentials in a service context which would be used by default.
> Existing methods that accept username and password would use simpler
> authenticators.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
