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.


Attachment: FusekiTestCase.tar.gz
Description: GNU Zip compressed data

Reply via email to