Re: Federated Query with credentials

[Andy Seaborne]

On 03/06/2021 10:10, Andy Seaborne wrote:
OK - managed to recreate the situation in 4.0.0 and confirmed the 
situation does not occur in 4.1.0.


     Andy


The logging of parse errors (server side) is poor

https://issues.apache.org/jira/browse/JENA-2113

(this does not get an error message back to the caller. HTTP/2 does not 
 have response messages).


Andy



On 03/06/2021 08:09, Jens Zurawski wrote:

Hi Andy,

erm, sorry, seems the test case then was too simple.

Ok, first, thanks for the info, I wasn't aware about the fact that 
QueryFactory is entirely local. I've made a test with 
parseCheckSPARQL(false) and conn.queryAsk(...) and I'm getting the 
same 400 Bad Request.


In fact a query which provokes a 500 Server Error is an update (e.g. 
INSERT) query. I've changed the test query a bit (the error already 
occurs with an empty dataset, so no sample data is needed) attached as 
InsertSPARQL.txt


In client I run with:
RDFConnectionFuseki.create()parseCheckSPARQL(false).build();
 conn.update(queryString);

Now the server answers with a 500 Server Error and a long stack trace 
in the server log (attached as StackTrace.txt). Without authentication 
it simply returns 204 No Content, so the query by itself is not 
provoking the error.
But from my new insights risen from your explanations, my guess is 
that it is "just" the escalated and not catched Exception from the 
underlying Query Parser in the server. So I think it will be fixed 
with 4.1.0, too.


Apart from that we've decided to use this IRI Authentication only as 
an interim solution and we want to move forward to let the server 
handle this authentications of federated queries. You already gave me 
some hints and pointers in one of your last replies and I'll try to go 
this way. Maybe I have some questions to this, but then I will start a 
new thread.


Thanks and cu
Jens



Am 02.06.2021 um 23:37 schrieb Andy Seaborne:


On 02/06/2021 12:22, Jens Zurawski wrote:


QueryFactory.create  is entirely local - it is the general parsing of 
a query string.


It has not gone to the Fuseki server (that happens at conn.query).

This is an error local to the application.

If I send the query string to the server, not have it parsed it 
locally, I get a 400 (bad request) because the query is not parsed. 
This is fixed in Jena 4.1.0.


To turn off local parsing:

RDFConnectionFuseki.create().parseCheckSPARQL(false)

and conn.query(queryString) or conn.queryAsk(String)

> Because 4.0.0 throws an HTTP 500 error and no warning.

Where is the 500?

The server log file will have a record of it and presumably a stack 
trace. 

Re: Federated Query with credentials

[Andy Seaborne]

OK - managed to recreate the situation in 4.0.0 and confirmed the 
situation does not occur in 4.1.0.


Andy

On 03/06/2021 08:09, Jens Zurawski wrote:

Hi Andy,

erm, sorry, seems the test case then was too simple.

Ok, first, thanks for the info, I wasn't aware about the fact that 
QueryFactory is entirely local. I've made a test with 
parseCheckSPARQL(false) and conn.queryAsk(...) and I'm getting the same 
400 Bad Request.


In fact a query which provokes a 500 Server Error is an update (e.g. 
INSERT) query. I've changed the test query a bit (the error already 
occurs with an empty dataset, so no sample data is needed) attached as 
InsertSPARQL.txt


In client I run with:
RDFConnectionFuseki.create()parseCheckSPARQL(false).build();
     conn.update(queryString);

Now the server answers with a 500 Server Error and a long stack trace in 
the server log (attached as StackTrace.txt). Without authentication it 
simply returns 204 No Content, so the query by itself is not provoking 
the error.
But from my new insights risen from your explanations, my guess is that 
it is "just" the escalated and not catched Exception from the underlying 
Query Parser in the server. So I think it will be fixed with 4.1.0, too.


Apart from that we've decided to use this IRI Authentication only as an 
interim solution and we want to move forward to let the server handle 
this authentications of federated queries. You already gave me some 
hints and pointers in one of your last replies and I'll try to go this 
way. Maybe I have some questions to this, but then I will start a new 
thread.


Thanks and cu
Jens



Am 02.06.2021 um 23:37 schrieb Andy Seaborne:


On 02/06/2021 12:22, Jens Zurawski wrote:


QueryFactory.create  is entirely local - it is the general parsing of 
a query string.


It has not gone to the Fuseki server (that happens at conn.query).

This is an error local to the application.

If I send the query string to the server, not have it parsed it 
locally, I get a 400 (bad request) because the query is not parsed. 
This is fixed in Jena 4.1.0.


To turn off local parsing:

RDFConnectionFuseki.create().parseCheckSPARQL(false)

and conn.query(queryString) or conn.queryAsk(String)

> Because 4.0.0 throws an HTTP 500 error and no warning.

Where is the 500?

The server log file will have a record of it and presumably a stack 
trace. 

Re: Federated Query with credentials

[Jens Zurawski]

Hi Andy,

erm, sorry, seems the test case then was too simple.

Ok, first, thanks for the info, I wasn't aware about the fact that 
QueryFactory is entirely local. I've made a test with 
parseCheckSPARQL(false) and conn.queryAsk(...) and I'm getting the same 
400 Bad Request.


In fact a query which provokes a 500 Server Error is an update (e.g. 
INSERT) query. I've changed the test query a bit (the error already 
occurs with an empty dataset, so no sample data is needed) attached as 
InsertSPARQL.txt


In client I run with:
RDFConnectionFuseki.create()parseCheckSPARQL(false).build();
    conn.update(queryString);

Now the server answers with a 500 Server Error and a long stack trace in 
the server log (attached as StackTrace.txt). Without authentication it 
simply returns 204 No Content, so the query by itself is not provoking 
the error.
But from my new insights risen from your explanations, my guess is that 
it is "just" the escalated and not catched Exception from the underlying 
Query Parser in the server. So I think it will be fixed with 4.1.0, too.


Apart from that we've decided to use this IRI Authentication only as an 
interim solution and we want to move forward to let the server handle 
this authentications of federated queries. You already gave me some 
hints and pointers in one of your last replies and I'll try to go this 
way. Maybe I have some questions to this, but then I will start a new 
thread.


Thanks and cu
Jens



Am 02.06.2021 um 23:37 schrieb Andy Seaborne:


On 02/06/2021 12:22, Jens Zurawski wrote:


QueryFactory.create  is entirely local - it is the general parsing of 
a query string.


It has not gone to the Fuseki server (that happens at conn.query).

This is an error local to the application.

If I send the query string to the server, not have it parsed it 
locally, I get a 400 (bad request) because the query is not parsed. 
This is fixed in Jena 4.1.0.


To turn off local parsing:

RDFConnectionFuseki.create().parseCheckSPARQL(false)

and conn.query(queryString) or conn.queryAsk(String)

> Because 4.0.0 throws an HTTP 500 error and no warning.

Where is the 500?

The server log file will have a record of it and presumably a stack 
trace. 


INSERT{
<#me>?myAddress.
?myAddress?myCountry.
}
WHERE{
  FILTER(SAMETERM(STR(?countryString),str(?memberCountryName)))
  BIND("THEcountryString"AS?countryString).
  SERVICE 
  { 
SELECT ?memberCountryName 
WHERE {
  FILTER(langMatches(lang(?memberCountryName),"de"))
   
 ?memberCountry.
  
?memberCountry?memberCountryName.
} 
LIMIT 30
  }
}
07:42:22 INFO  Fuseki  :: [58] POST 
http://10.42.43.64:3030/estate/update
07:42:22 INFO  Fuseki  :: [58] Update
07:42:22 ERROR SPARQL  :: [line: 1, col: 289] Bad IRI: 
'http://admin:pw@10.42.43.64:3030/estate/query': 
 Code: 
58/PROHIBITED_COMPONENT_PRESENT in USER: A component that is prohibited by the 
scheme is present.
07:42:22 WARN  Fuseki  :: [58] ActionErrorException with cause
org.apache.jena.fuseki.servlets.ActionErrorException: [line: 1, col: 289] Bad 
IRI: 'http://admin:pw@10.42.43.64:3030/estate/query': 
 Code: 
58/PROHIBITED_COMPONENT_PRESENT in USER: A component that is prohibited by the 
scheme is present.
at 
org.apache.jena.fuseki.servlets.ServletOps.errorOccurred(ServletOps.java:202) 
~[fuseki-server.jar:4.0.0]
at 
org.apache.jena.fuseki.servlets.SPARQL_Update.execute(SPARQL_Update.java:248) 
~[fuseki-server.jar:4.0.0]
at 
org.apache.jena.fuseki.servlets.SPARQL_Update.executeBody(SPARQL_Update.java:188)
 ~[fuseki-server.jar:4.0.0]
at 
org.apache.jena.fuseki.servlets.SPARQL_Update.execute(SPARQL_Update.java:103) 
~[fuseki-server.jar:4.0.0]
at 
org.apache.jena.fuseki.servlets.ActionService.executeLifecycle(ActionService.java:58)
 ~[fuseki-server.jar:4.0.0]
at 
org.apache.jena.fuseki.servlets.SPARQL_Update.execPost(SPARQL_Update.java:88) 
~[fuseki-server.jar:4.0.0]
at 
org.apache.jena.fuseki.servlets.ActionProcessor.process(ActionProcessor.java:34)
 ~[fuseki-server.jar:4.0.0]
at 
org.apache.jena.fuseki.servlets.ActionBase.process(ActionBase.java:55) 
~[fuseki-server.jar:4.0.0]
at 
org.apache.jena.fuseki.servlets.ActionExecLib.execAction(ActionExecLib.java:108)
 ~[fuseki-server.jar:4.0.0]
at 
org.apache.jena.fuseki.server.Dispatcher.dispatchAction(Dispatcher.java:118) 
~[fuseki-server.jar:4.0.0]
at 
org.apache.jena.fuseki.server.Dispatcher.process(Dispatcher.java:110) 
~[fuseki-server.jar:4.0.0]
at 
org.apache.jena.fuseki.server.Dispatcher.dispa

Re: Federated Query with credentials

[Andy Seaborne]

On 02/06/2021 12:22, Jens Zurawski wrote:

Hi Andy,

I was able to construct a really simple test case to reliably 
reproduce our problem. I've started with a vanilla ubuntu 20.04 VM to 
eliminate potential and disturbing other problems from misconfigs or 
the like.


used JDK: openjdk version "14.0.2" 2020-07-14

Now the steps to reproduce:

 1. download apache-jena-fuseki-4.0.0.tar.gz from
https://jena.apache.org/download/
 2. unpack archive and initial start fuseki-server to create default
run environment of fuseki
 3. stop fuseki and make only small changes to run/shiro.ini to set up
authentication (see below for exact content, I just made a few
changes to the default)
 4. start fuseki again with fuseki-server and create an empty dataset
"estate"
 5. Build simple Java Application (attached to the mail, I hope it's
possible to attach small files to list-mails,
FusekiTestCase.tar.gz, basically just a pom and a Main class) and
run it
 6. On the line "Query fusekiQuery =
QueryFactory.create(queryString);" it raises the Exception:
org.apache.jena.query.QueryException: [line: 1, col: 125] Bad IRI:
'http://admin:pw@10.42.43.64:3030/estate/query':
 Code:
58/PROHIBITED_COMPONENT_PRESENT in USER: A component that is
prohibited by the scheme is present.

QueryFactory.create  is entirely local - it is the general parsing of a 
query string.


It has not gone to the Fuseki server (that happens at conn.query).

This is an error local to the application.

If I send the query string to the server, not have it parsed it locally, 
I get a 400 (bad request) because the query is not parsed. This is fixed 
in Jena 4.1.0.


To turn off local parsing:

RDFConnectionFuseki.create().parseCheckSPARQL(false)

and conn.query(queryString) or conn.queryAsk(String)

> Because 4.0.0 throws an HTTP 500 error and no warning.

Where is the 500?

The server log file will have a record of it and presumably a stack trace.



 1. Application aborts then
 2. If you just remove the credentials from the SRVICE IRI, you get
the expected and correct Exception:
HttpException: 401 Unauthorized
 3. If you remove credentials from the SERVICE IRI and reconfigure
shiro.ini so that the dataset is no longer secured, the
application runs without errors and gives back a "false" for the
ASK Query (which is correct, because the estate dataset is empty)


That is what I would expect.
I hope this will help you to understand and reproduce my problem. 
Because I'm relative new to the Jena API, maybe it's just a dumb 
mistake from me in using the API, then a hint of what I'm doing wrong 
would be more than welcome ;-)


Thank you again for taking a look into this.
Jens


The slightly altered shiro.ini (comments and empty lines removed):
8<--
[main]
ssl.enabled = false
plainMatcher=org.apache.shiro.authc.credential.SimpleCredentialsMatcher
iniRealm.credentialsMatcher = $plainMatcher
localhostFilter=org.apache.jena.fuseki.authz.LocalhostFilter
[users]
admin=pw, all
[roles]
all = *
[urls]
/$/status  = anon
/$/server  = anon
/$/ping    = anon
/$/metrics = anon
/$/** = authcBasic, roles[all]
/** = authcBasic, roles[all]
8<--



Am 27.05.2021 um 11:18 schrieb Jens Zurawski:

Hi Andy,

thanks for your effort on trying to reproduce our case.

I'm using the binary package apache-jena-fuseki-4.0.0.tar.gz from 
https://jena.apache.org/download/index.cgi with open jdk 11. The 
configuration isn't altered much from the package defaults, mainly 
the shiro.ini config for securing the access.


The used query is pretty complex I don't want to bother you with 
this. So I will check again on my environment in order to get more 
detailed information and will try to create a simple reproduceable 
test case for you.


I will come back to this next week.
Jens


Am 27.05.2021 um 10:27 schrieb Andy Seaborne:

Jens -

When I tried to recreate this with 4.0.0 but I get "400 Bad request" 
not a 500 (and it works in development).


Which binary packaging are you using?
What is the server configuration?
What is the query with the SERVICE in it?
What does the log have in it for the request?

    Andy

On 26/05/2021 21:33, Andy Seaborne wrote:



On 26/05/2021 18:08, Jens Zurawski wrote:

Hi Andy, hi list,

...
Does that mean that in future versions the IRI method will work 
again but only put some warnings? Because 4.0.0 throws an HTTP 500 
error and no warning.

Re: Federated Query with credentials

[Jens Zurawski]

Hi Andy,

I was able to construct a really simple test case to reliably reproduce 
our problem. I've started with a vanilla ubuntu 20.04 VM to eliminate 
potential and disturbing other problems from misconfigs or the like.


used JDK: openjdk version "14.0.2" 2020-07-14

Now the steps to reproduce:

1. download apache-jena-fuseki-4.0.0.tar.gz from
   https://jena.apache.org/download/
2. unpack archive and initial start fuseki-server to create default run
   environment of fuseki
3. stop fuseki and make only small changes to run/shiro.ini to set up
   authentication (see below for exact content, I just made a few
   changes to the default)
4. start fuseki again with fuseki-server and create an empty dataset
   "estate"
5. Build simple Java Application (attached to the mail, I hope it's
   possible to attach small files to list-mails, FusekiTestCase.tar.gz,
   basically just a pom and a Main class) and run it
6. On the line "Query fusekiQuery = QueryFactory.create(queryString);"
   it raises the Exception:
   org.apache.jena.query.QueryException: [line: 1, col: 125] Bad IRI:
   'http://admin:pw@10.42.43.64:3030/estate/query':
    Code:
   58/PROHIBITED_COMPONENT_PRESENT in USER: A component that is
   prohibited by the scheme is present.
7. Application aborts then
8. If you just remove the credentials from the SRVICE IRI, you get the
   expected and correct Exception:
   HttpException: 401 Unauthorized
9. If you remove credentials from the SERVICE IRI and reconfigure
   shiro.ini so that the dataset is no longer secured, the application
   runs without errors and gives back a "false" for the ASK Query
   (which is correct, because the estate dataset is empty)


I hope this will help you to understand and reproduce my problem. 
Because I'm relative new to the Jena API, maybe it's just a dumb mistake 
from me in using the API, then a hint of what I'm doing wrong would be 
more than welcome ;-)


Thank you again for taking a look into this.
Jens


The slightly altered shiro.ini (comments and empty lines removed):
8<--
[main]
ssl.enabled = false
plainMatcher=org.apache.shiro.authc.credential.SimpleCredentialsMatcher
iniRealm.credentialsMatcher = $plainMatcher
localhostFilter=org.apache.jena.fuseki.authz.LocalhostFilter
[users]
admin=pw, all
[roles]
all = *
[urls]
/$/status  = anon
/$/server  = anon
/$/ping    = anon
/$/metrics = anon
/$/** = authcBasic, roles[all]
/** = authcBasic, roles[all]
8<--



Am 27.05.2021 um 11:18 schrieb Jens Zurawski:

Hi Andy,

thanks for your effort on trying to reproduce our case.

I'm using the binary package apache-jena-fuseki-4.0.0.tar.gz from 
https://jena.apache.org/download/index.cgi with open jdk 11. The 
configuration isn't altered much from the package defaults, mainly the 
shiro.ini config for securing the access.


The used query is pretty complex I don't want to bother you with this. 
So I will check again on my environment in order to get more detailed 
information and will try to create a simple reproduceable test case 
for you.


I will come back to this next week.
Jens


Am 27.05.2021 um 10:27 schrieb Andy Seaborne:

Jens -

When I tried to recreate this with 4.0.0 but I get "400 Bad request" 
not a 500 (and it works in development).


Which binary packaging are you using?
What is the server configuration?
What is the query with the SERVICE in it?
What does the log have in it for the request?

    Andy

On 26/05/2021 21:33, Andy Seaborne wrote:



On 26/05/2021 18:08, Jens Zurawski wrote:

Hi Andy, hi list,

...
Does that mean that in future versions the IRI method will work 
again but only put some warnings? Because 4.0.0 throws an HTTP 500 
error and no warning.






FusekiTestCase.tar.gz
Description: GNU Zip compressed data

Re: Federated Query with credentials

[Jens Zurawski]

Hi Andy,

thanks for your effort on trying to reproduce our case.

I'm using the binary package apache-jena-fuseki-4.0.0.tar.gz from 
https://jena.apache.org/download/index.cgi with open jdk 11. The 
configuration isn't altered much from the package defaults, mainly the 
shiro.ini config for securing the access.


The used query is pretty complex I don't want to bother you with this. 
So I will check again on my environment in order to get more detailed 
information and will try to create a simple reproduceable test case for you.


I will come back to this next week.
Jens


Am 27.05.2021 um 10:27 schrieb Andy Seaborne:

Jens -

When I tried to recreate this with 4.0.0 but I get "400 Bad request" 
not a 500 (and it works in development).


Which binary packaging are you using?
What is the server configuration?
What is the query with the SERVICE in it?
What does the log have in it for the request?

    Andy

On 26/05/2021 21:33, Andy Seaborne wrote:



On 26/05/2021 18:08, Jens Zurawski wrote:

Hi Andy, hi list,

...
Does that mean that in future versions the IRI method will work 
again but only put some warnings? Because 4.0.0 throws an HTTP 500 
error and no warning.


--
jens zurawski
diegurus - zurawski zurawski poppl rohland GbR
juister straße 3
65199 wiesbaden

kaspersweg 7b
26131 oldenburg

internet http://www.diegurus.de

tel +49(0)611 72437966


CONFIDENTIALITY NOTICE: This e-mail message is intended only for the
person or entity to which it is addressed and may contain confidential
and/or privileged material. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply e-mail and destroy all copies of the
original message.  If you are the intended recipient but do not wish to
receive communications through this medium, please so advise the sender
immediately.

Re: Federated Query with credentials

[Andy Seaborne]

Jens -

When I tried to recreate this with 4.0.0 but I get "400 Bad request" not 
a 500 (and it works in development).


Which binary packaging are you using?
What is the server configuration?
What is the query with the SERVICE in it?
What does the log have in it for the request?

Andy

On 26/05/2021 21:33, Andy Seaborne wrote:



On 26/05/2021 18:08, Jens Zurawski wrote:

Hi Andy, hi list,

...
Does that mean that in future versions the IRI method will work again 
but only put some warnings? Because 4.0.0 throws an HTTP 500 error and 
no warning.

Re: Federated Query with credentials

[Andy Seaborne]

On 26/05/2021 18:08, Jens Zurawski wrote:

Hi Andy, hi list,

because I'm new to the list, I wasn't able to directly reply to the 
corresponding thread. I'm referring to the equal named thread "Federated 
Query with credentials" from the past days.


I am a good skilled Java developer, but my knowledge about Jena, Fuseki 
and SPARQL is quite limited, so please don't shoot me if I'm asking some 
obvious or silly questions. ;-)


Andy, from my understanding the solution you've outlined in your last 
reply to this thread is only working if the requester (aka the 
application) and the query executor (aka the fuseki server) is running 
in the same Java VM, right? It is not possible to pass an HttpClient 
instance from one JVM to another or even to another machine. So this 
will not work in our scenario.


We have an application separated from the fuseki server (we are using 
the binary pre build package). So with RDFConnectionRemoteBuilder it is 
no problem to create a normal Request with an customized HttpClient 
using our CredentialProvider. But in case the Query includes a SERVICE 
subquery to a different dataset or even a different host, from what I 
think, the request for this subquery is then initiated by fuseki, right?


For this to work we have to tell fuseki the credentials to use on one 
way or the other. In the past we've done that together with the IRI. 
It's not perfect but it worked until 4.0.0.


In your last reply you've said:

"In 4.0.0 it can be overzealous
It will remain a wanring, but be passed through."

Does that mean that in future versions the IRI method will work again 
but only put some warnings? Because 4.0.0 throws an HTTP 500 error and 
no warning.


Yes - you can try the development builds where it should be fixed.


Our needed SERVICE IRIs are somewhat static, so it would fully suffice 
if there would be a possibility to just configure the fuseki server with 
some credentials to some IRIs. Is this possible somehow? Or would we 
have to build our own fuseki with an enhacement to give an own 
CredentialsProvider to the default HttpClient?


Fuseki Main is more flexible and easier to add Java to. (No UI.) The CLI 
is driving the server builder.


A custom app can call the CLI as well - it's just a main function.

That makes setting up the SERVICE environment possible.

Andy



thanks in advance for some insigths
Jens

Federated Query with credentials

[Jens Zurawski]

Hi Andy, hi list,

because I'm new to the list, I wasn't able to directly reply to the 
corresponding thread. I'm referring to the equal named thread "Federated 
Query with credentials" from the past days.


I am a good skilled Java developer, but my knowledge about Jena, Fuseki 
and SPARQL is quite limited, so please don't shoot me if I'm asking some 
obvious or silly questions. ;-)


Andy, from my understanding the solution you've outlined in your last 
reply to this thread is only working if the requester (aka the 
application) and the query executor (aka the fuseki server) is running 
in the same Java VM, right? It is not possible to pass an HttpClient 
instance from one JVM to another or even to another machine. So this 
will not work in our scenario.


We have an application separated from the fuseki server (we are using 
the binary pre build package). So with RDFConnectionRemoteBuilder it is 
no problem to create a normal Request with an customized HttpClient 
using our CredentialProvider. But in case the Query includes a SERVICE 
subquery to a different dataset or even a different host, from what I 
think, the request for this subquery is then initiated by fuseki, right?


For this to work we have to tell fuseki the credentials to use on one 
way or the other. In the past we've done that together with the IRI. 
It's not perfect but it worked until 4.0.0.


In your last reply you've said:

"In 4.0.0 it can be overzealous
It will remain a wanring, but be passed through."

Does that mean that in future versions the IRI method will work again 
but only put some warnings? Because 4.0.0 throws an HTTP 500 error and 
no warning.


Our needed SERVICE IRIs are somewhat static, so it would fully suffice 
if there would be a possibility to just configure the fuseki server with 
some credentials to some IRIs. Is this possible somehow? Or would we 
have to build our own fuseki with an enhacement to give an own 
CredentialsProvider to the default HttpClient?


thanks in advance for some insigths
Jens

Re: Federated Query with credentials

[Andy Seaborne]

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 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  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  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

Re: Federated Query with credentials

[Bardo Nelgen]

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.

until I remove the credentials from the  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  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

Re: Federated Query with credentials

[Andy Seaborne]

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  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

Federated Query with credentials

[Bardo Nelgen]

Hi all,

on good old Fuseki 2.6.0 I could use the IRL of  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