[jira] [Commented] (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=13701017#comment-13701017 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #764 (See [https://builds.apache.org/job/Jena__Development_Test/764/]) Fix bug in FormsAuthenticator caused by spurious toString() call in map lookup (JENA-480) (Revision 1500079) Result = SUCCESS rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/FormsAuthenticator.java * /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/util/LocatorURL.java > 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: 101h > Remaining Estimate: 0h > > 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
[jira] [Commented] (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=13701014#comment-13701014 ] ASF subversion and git services commented on JENA-480: -- Commit 1500079 from [~rvesse] [ https://svn.apache.org/r1500079 ] Fix bug in FormsAuthenticator caused by spurious toString() call in map lookup (JENA-480) > 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: 101h > Remaining Estimate: 0h > > 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
[jira] [Commented] (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=13699447#comment-13699447 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #757 (See [https://builds.apache.org/job/Jena__Development_Test/757/]) Simplify constant names (JENA-480) (Revision 1499556) Make a couple of constants public (JENA-480) (Revision 1499555) Result = SUCCESS rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/ApacheModAuthFormLogin.java rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/ApacheModAuthFormLogin.java > 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: 101h > Remaining Estimate: 0h > > 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
[jira] [Commented] (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=13699428#comment-13699428 ] ASF subversion and git services commented on JENA-480: -- Commit 1499555 from [~rvesse] [ https://svn.apache.org/r1499555 ] Make a couple of constants public (JENA-480) > 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: 101h > Remaining Estimate: 0h > > 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
[jira] [Commented] (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=13699433#comment-13699433 ] ASF subversion and git services commented on JENA-480: -- Commit 1499556 from [~rvesse] [ https://svn.apache.org/r1499556 ] Simplify constant names (JENA-480) > 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: 101h > Remaining Estimate: 0h > > 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
[jira] [Commented] (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=13699173#comment-13699173 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #755 (See [https://builds.apache.org/job/Jena__Development_Test/755/]) Add overloads for QueryExecutionFactory.sparqlService() that take HttpAuthenticator (JENA-480) (Revision 1499471) Result = SUCCESS rvesse : Files : * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/query/QueryExecutionFactory.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/http/QueryEngineHTTP.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessRemote.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessRemoteForm.java > 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: 101h > Remaining Estimate: 0h > > 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
[jira] [Commented] (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=13699159#comment-13699159 ] ASF subversion and git services commented on JENA-480: -- Commit 1499471 from [~rvesse] [ https://svn.apache.org/r1499471 ] Add overloads for QueryExecutionFactory.sparqlService() that take HttpAuthenticator (JENA-480) > 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: 101h > Remaining Estimate: 0h > > 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
[jira] [Commented] (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=13699156#comment-13699156 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #754 (See [https://builds.apache.org/job/Jena__Development_Test/754/]) Add overloads for UpdateExecutionFactory.createRemote() and createRemoteForm() that take HttpAuthenticator (JENA-480) (Revision 1499466) Result = UNSTABLE rvesse : Files : * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/Optimize.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessRemote.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessRemoteForm.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/update/UpdateExecutionFactory.java > 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: 101h > Remaining Estimate: 0h > > 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
[jira] [Commented] (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=13699147#comment-13699147 ] ASF subversion and git services commented on JENA-480: -- Commit 1499466 from [~rvesse] [ https://svn.apache.org/r1499466 ] Add overloads for UpdateExecutionFactory.createRemote() and createRemoteForm() that take HttpAuthenticator (JENA-480) > 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: 101h > Remaining Estimate: 0h > > 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
[jira] [Commented] (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=13699134#comment-13699134 ] Rob Vesse commented on JENA-480: Documentation is done, all I have left to do is to add some method overloads to relevant factories to take in authenticators at creation time. > 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: 101h > Remaining Estimate: 0h > > 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
[jira] [Commented] (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=13698420#comment-13698420 ] Rob Vesse commented on JENA-480: A staging draft of the new documentation page can be found at http://jena.staging.apache.org/documentation/query/http-auth.html This is not yet finished > 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
[jira] [Commented] (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=13698375#comment-13698375 ] Rob Vesse commented on JENA-480: I notice that LocatorURL exists in both jena-core and jena-arq, since LocatorURL is fairly low level I will not adapt the jena-arq version. Users can still configure the default authenticator since LocatorURL goes through HttpOp anyway. Is there anything else in ARQ that uses HTTP and needs to be updated to go through HttpOp? In the meantime I will start adding a new documentation page explaining the new functionality. > 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
[jira] [Commented] (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=13697344#comment-13697344 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #749 (See [https://builds.apache.org/job/Jena__Development_Test/749/]) Add a delegating authenticator which can be used to map different authenticators to different URIs (JENA-480) (Revision 1498721) Rework scoped authenticators to work more sensibly (JENA-480) Credentials are now scoped to any URI derived from them e.g. credentials for http://example.org also apply to http://example.org/some/path However longest match applies since we work backwards from the requested URI so if credentials for http://example.org/some/path were present they would be used instead Added additional tests to validate these changes (Revision 1498718) Result = FAILURE rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/DelegatingAuthenticator.java rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/AbstractCredentialsAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/AbstractScopedAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/FormLogin.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/FormsAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/ScopedAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/ServiceAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/SimpleAuthenticator.java * /jena/trunk/jena-fuseki/src/test/java/org/apache/jena/fuseki/TestAuth.java > 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
[jira] [Commented] (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 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
[jira] [Commented] (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=13697254#comment-13697254 ] ASF subversion and git services commented on JENA-480: -- Commit 1498721 from [~rvesse] [ https://svn.apache.org/r1498721 ] Add a delegating authenticator which can be used to map different authenticators to different URIs (JENA-480) > 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
[jira] [Commented] (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=13697246#comment-13697246 ] ASF subversion and git services commented on JENA-480: -- Commit 1498718 from [~rvesse] [ https://svn.apache.org/r1498718 ] Rework scoped authenticators to work more sensibly (JENA-480) Credentials are now scoped to any URI derived from them e.g. credentials for http://example.org also apply to http://example.org/some/path However longest match applies since we work backwards from the requested URI so if credentials for http://example.org/some/path were present they would be used instead Added additional tests to validate these changes > 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
[jira] [Commented] (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=13697167#comment-13697167 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #748 (See [https://builds.apache.org/job/Jena__Development_Test/748/]) Add authentication support to DatasetGraphAccessorHTTP, start adding some tests for this (JENA-480) (Revision 1498680) Clean up javadoc in HttpOp (JENA-480) (Revision 1498666) Result = SUCCESS rvesse : Files : * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/query/DatasetAccessorFactory.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/web/DatasetGraphAccessorHTTP.java * /jena/trunk/jena-fuseki/src/test/java/org/apache/jena/fuseki/TestAuth.java * /jena/trunk/jena-text/pom.xml rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/web/HttpOp.java > 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
[jira] [Commented] (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=13697163#comment-13697163 ] ASF subversion and git services commented on JENA-480: -- Commit 1498680 from [~rvesse] [ https://svn.apache.org/r1498680 ] Add authentication support to DatasetGraphAccessorHTTP, start adding some tests for this (JENA-480) > 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
[jira] [Commented] (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=13697129#comment-13697129 ] ASF subversion and git services commented on JENA-480: -- Commit 1498666 from [~rvesse] [ https://svn.apache.org/r1498666 ] Clean up javadoc in HttpOp (JENA-480) > 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
[jira] [Commented] (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=13695984#comment-13695984 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #739 (See [https://builds.apache.org/job/Jena__Development_Test/739/]) Add some logging to Forms Authenticator (JENA-480) (Revision 1497958) Result = SUCCESS rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/FormsAuthenticator.java > 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
[jira] [Commented] (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=13695948#comment-13695948 ] Rob Vesse commented on JENA-480: Put some finishing touches to forms authentication support today. Verified that this works correctly against our in house systems which use Apache mod_auth_form to provide forms based authentication. > 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
[jira] [Commented] (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=13695941#comment-13695941 ] ASF subversion and git services commented on JENA-480: -- Commit 1497958 from [~rvesse] [ https://svn.apache.org/r1497958 ] Add some logging to Forms Authenticator (JENA-480) > 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
[jira] [Commented] (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=13695935#comment-13695935 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #738 (See [https://builds.apache.org/job/Jena__Development_Test/738/]) Ensure FormsAuthenticator frees up the connection used for the login (JENA-480) (Revision 1497957) Result = FAILURE rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/FormsAuthenticator.java > 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
[jira] [Commented] (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=13695933#comment-13695933 ] ASF subversion and git services commented on JENA-480: -- Commit 1497957 from [~rvesse] [ https://svn.apache.org/r1497957 ] Ensure FormsAuthenticator frees up the connection used for the login (JENA-480) > 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
[jira] [Commented] (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=13695644#comment-13695644 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #737 (See [https://builds.apache.org/job/Jena__Development_Test/737/]) Allow PreemptiveBasicAuthenticator to do preemptive standard/proxy auth as required (JENA-480) Fix up other log4j properties files to include Apache HTTP settings (Revision 1497861) Result = SUCCESS rvesse : Files : * /jena/trunk/jena-arq/log4j.properties * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/PreemptiveBasicAuthenticator.java * /jena/trunk/jena-arq/src/test/resources/log4j-testing.properties * /jena/trunk/jena-arq/src/test/resources/log4j.properties > 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
[jira] [Commented] (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=13695608#comment-13695608 ] ASF subversion and git services commented on JENA-480: -- Commit 1497861 from [~rvesse] [ https://svn.apache.org/r1497861 ] Allow PreemptiveBasicAuthenticator to do preemptive standard/proxy auth as required (JENA-480) Fix up other log4j properties files to include Apache HTTP settings > 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
[jira] [Commented] (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=13695118#comment-13695118 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #731 (See [https://builds.apache.org/job/Jena__Development_Test/731/]) Expand authentication tests to use different authenticators (JENA-480) (Revision 1497584) Finish converting SPARQL Query code to new unified HTTP framework and support broader authentication for SPARQL Queries (JENA-480) Started work on adding support for Forms based authentication (Revision 1497583) Result = SUCCESS rvesse : Files : * /jena/trunk/jena-fuseki/src/test/java/org/apache/jena/fuseki/TestAuth.java rvesse : Files : * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/http/HttpQuery.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/http/QueryEngineHTTP.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/http/QueryExceptionHTTP.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessRemote.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/HttpException.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/ApacheModAuthFormLogin.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/FormLogin.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/FormsAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/ServiceAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/web/HttpOp.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/web/DatasetGraphAccessorHTTP.java * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/engine/http/TestService.java > 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
[jira] [Commented] (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=13695109#comment-13695109 ] ASF subversion and git services commented on JENA-480: -- Commit 1497584 from [~rvesse] [ https://svn.apache.org/r1497584 ] Expand authentication tests to use different authenticators (JENA-480) > 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
[jira] [Commented] (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=13695108#comment-13695108 ] ASF subversion and git services commented on JENA-480: -- Commit 1497583 from [~rvesse] [ https://svn.apache.org/r1497583 ] Finish converting SPARQL Query code to new unified HTTP framework and support broader authentication for SPARQL Queries (JENA-480) Started work on adding support for Forms based authentication > 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
[jira] [Commented] (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=13695070#comment-13695070 ] Rob Vesse commented on JENA-480: I have the HttpQuery refactoring essentially done, this required a little more refactoring of HttpOp since controlling timeouts requires manipulating HttpClient parameters. Btw it may be useful to provide a default set of HttpClientParameters that can be modified on a global level. I've added some additional tests for HTTP auth that verify that the revised framework does work as expected and will be checking these in with my latest changes shortly. > 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
[jira] [Commented] (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=13694980#comment-13694980 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #729 (See [https://builds.apache.org/job/Jena__Development_Test/729/]) Update authenticaiton for SPARQL Updates to use new authentication framework (JENA-480) (Revision 1497512) Heavily refactored HttpOp to use the new authentication framework (JENA-480) Note that existing API methods are retained for backwards compatibility (Revision 1497510) Unified and extensible authentication framework for Atlas (JENA-480) (Revision 1497509) Result = SUCCESS rvesse : Files : * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessRemote.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessRemoteBase.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessRemoteForm.java rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/web/HttpOp.java rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/HttpException.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/AbstractCredentialsAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/AbstractScopedAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/HttpAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/PreemptiveBasicAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/ScopedAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/ServiceAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/SimpleAuthenticator.java > 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
[jira] [Commented] (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=13694972#comment-13694972 ] Rob Vesse commented on JENA-480: I have made the initial commits related to this today, these commits include the following: - First pass of the new authentication framework - Heavily refactored HttpOp to add overloads that take HttpAuthenticator instances - Updated SPARQL Updates to use new authentication framework I have started work on converting HttpQuery to use HttpOp and thus the new authentication framework but I need to do some more work to appropriately enable gzip/deflate encoding and timeouts. > 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
[jira] [Commented] (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=13694970#comment-13694970 ] ASF subversion and git services commented on JENA-480: -- Commit 1497512 from [~rvesse] [ https://svn.apache.org/r1497512 ] Update authenticaiton for SPARQL Updates to use new authentication framework (JENA-480) > 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
[jira] [Commented] (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=13694969#comment-13694969 ] ASF subversion and git services commented on JENA-480: -- Commit 1497510 from [~rvesse] [ https://svn.apache.org/r1497510 ] Heavily refactored HttpOp to use the new authentication framework (JENA-480) Note that existing API methods are retained for backwards compatibility > 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
[jira] [Commented] (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=13694967#comment-13694967 ] ASF subversion and git services commented on JENA-480: -- Commit 1497509 from [~rvesse] [ https://svn.apache.org/r1497509 ] Unified and extensible authentication framework for Atlas (JENA-480) > 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
[jira] [Commented] (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=13694848#comment-13694848 ] Rob Vesse commented on JENA-480: Also we can avoid some of the awkward code we currently have for using compressed encodings and utilize the DecompressingHttpClient decorator > 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 > Remaining Estimate: 72h > > 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
[jira] [Commented] (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=13694847#comment-13694847 ] Rob Vesse commented on JENA-480: Another thing to unify is that currently we use DefaultHttpClient where SystemDefaultHttpClient would be preferable since that respects various Java system properties wrt certificates, proxies etc. > 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 > Remaining Estimate: 72h > > 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
