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.
FusekiTestCase.tar.gz
Description: GNU Zip compressed data