Ah - I read it as using SERVICE so you could send auth conveniently
which I have seen before.
The query execution context can have a HttpClient passed to it.
I thought this was in the documentation or an example somewhere but I
can't find it.
https://jena.apache.org/documentation/javadoc/arq/org/apache/jena/sparql/engine/http/Service.html
and examples of use from the tests:
https://github.com/apache/jena/blob/main/jena-arq/src/test/java/org/apache/jena/sparql/engine/http/TestService.java
which at its core is:
String serviceURL = "http://....";;
// Put in a map of Service URL to context inthe global context
// (Can be per query rather than global if desired)
Map<String, Context> serviceContextMap = new HashMap<>();
ARQ.getContext().put(Service.serviceContext, serviceContextMap);
// Create context with HttpClient.
Context serviceContext = new Context(ARQ.getContext());
HttpClient testClient = HttpClients.custom().build(); // Add auth
serviceContext.put(Service.queryClient, testClient);
// Put in global map for serviceURL
serviceContextMap.put(serviceURL, new Context(ARQ.getContext()));
.. make query...
Andy
On 20/05/2021 12:13, Bardo Nelgen wrote:
Thanks a lot, Andy.
And sorry, it seems I probably formulated my question the wrong way around:
How can I use your described approach for a federated sub-query, for
which (as it is embedded inside an outer query) one seemingly cannot
easily transmit separate/different credentials via
RDFConnectionRemoteBuilder.
As mentioned, formerly I simply put the credentials inside the federated
IRL, which was fine, as it’s just going to localhost for now.
But since the update to the latest Jena/Fuseki version, I keep getting a
"Bad IRI" error
Code: 58/PROHIBITED_COMPONENT_PRESENT in USER: A component that is
prohibited by the scheme is present.
In 4.0.0 it can be overzealous
It will remain a wanring, but be passed through.
Using the HttpClient mechanism is better.
until I remove the credentials from the <service> IRL.
For the outer query, of course, RDFConnectionRemoteBuilder does the job
as expected (with Fuseki running in a different context than the main
application; in future possibly on a separate machine).
Quite obviously, I’m missing something here… – just have absolutely no
clue any more what it might be.
Probably something with the "credsProvider"/"AuthSetup" features ? Or a
preset/config file to be placed somewhere ?
Again, thanks for looking into this.
Best,
Bardo
On 19.05.21 19.34 Uhr, Andy Seaborne wrote:
Bardo,
On the server side:
https://jena.apache.org/documentation/fuseki2/fuseki-data-access-control.html
Access control on the server, dataset URL, or endpoint.
Also on the data with graph access control lists.
You can also use Apache Shiro.
https://jena.apache.org/documentation/fuseki2/fuseki-security
and
https://jena.apache.org/documentation/permissions/
On the client side:
https://jena.apache.org/documentation/rdfconnection/
RDFConnectionRemoteBuilder
and pass in an appropriate HttpClient (Apache HttpClient).
Andy
On 19/05/2021 10:36, Bardo Nelgen wrote:
Hi all,
on good old Fuseki 2.6.0 I could use the IRL of <SERVICE> requests to
transmit required HTTP basic credentials to access Fuseki.
Obviously this is not possible any longer with the current version –
not even for localhost.
As using a reverse proxy to restrict access even from the local
environment to me appears somewhat impractical:
What is the "correct" way to locally control Fuseki access while
still intending to play by the rules ? :-)
As always, any hint or pointer is highly appreciated.
Best,
Bardo
