You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Jens Zurawski <jz...@diegurus.de> on 2021/06/02 11:22:34 UTC
Re: Federated Query with credentials
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':
<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.
>
Re: Federated Query with credentials
Posted by Andy Seaborne <an...@apache.org>.
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
Posted by Andy Seaborne <an...@apache.org>.
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
Posted by Jens Zurawski <jz...@diegurus.de>.
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
Posted by Andy Seaborne <an...@apache.org>.
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':
> <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.
>>
>