You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Rob Vesse (JIRA)" <ji...@apache.org> on 2013/07/02 00:19:20 UTC

[jira] [Comment Edited] (JENA-480) Unify HTTP usage and authentication mechanisms in ARQ

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

Rob Vesse edited comment on JENA-480 at 7/1/13 10:17 PM:
---------------------------------------------------------

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.  So taking our previous example if we also had credentials for http://example.org/some/path they would always be selected over those for http://example.org

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.
                
      was (Author: rvesse):
    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