-
Notifications
You must be signed in to change notification settings - Fork 650
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
jena-fuseki-access - Propagate request/service context #1291
base: main
Are you sure you want to change the base?
Conversation
.query(query) | ||
.context(action.getContext()) | ||
; | ||
// Note: Instead of this call (and the above build), the equivalent code from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Repeating the same step here for timeout seems not right (but I wasn't sure what a better / the right approach would be).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use-case sounds good to me. Not sure about the implementation either, so probably needs @afs 's review here.
Thanks!
(also need to confirm all tests pass in Jenkins or GH Actions [manual])
From users@ thread https://lists.apache.org/thread/h0c81qjl8oc83yl2xf7xvt4l0pw4grrf It looks like there is an issue as to whether the text dataset should push down the context setting for the index or not. Requiring endpoint configuration isn't so user-friendly. This PR may contain a change to make anyway but this jena-fuseki-access uses context settings An outstanding question from email:
It'll need some tests. |
(copied from thread reply): Yes it does - three (expected) warnings from TextQueryPF:
I'd be happy to assist with this (time permitting) if I'm pointed in the right direction. |
Apologies - I updated the description since it had a mistake. The expected behaviour section has changed to:
|
(Changing to draft as suggested, since the best way to address this is still being debated.) |
- Requires context propagation patch (see apache#1291) - Comment specified before query can be used to override security context with a given set of graphs. - Overridden security context is preserved in the execution context - Simplified regex pattern only - has to be first non-whitespace line to work.
- Requires context propagation patch (see apache#1291) - Comment specified before query can be used to override security context with a given set of graphs. - Overridden security context is preserved in the execution context - Simplified regex pattern only - has to be first non-whitespace line to work.
- Requires context propagation patch (see apache#1291) - Comment specified before query can be used to override security context with a given set of graphs. - Overridden security context is preserved in the execution context - Simplified regex pattern only - has to be first non-whitespace line to work.
- "#pragma acl.graphs" preamble can be used to specify one or more graphs to restriction query exectution to - The functionality is only enabled if an access:entry for a specific user contains just <urn:jena:accessGraphsDynamic> - Requires context propagation patch (see apache#1291), since query is stored in request-specific context
- "#pragma acl.graphs" preamble can be used to specify one or more graphs to restriction query exectution to - The functionality is only enabled if an access:entry for a specific user contains just <urn:jena:accessGraphsDynamic> - Requires context propagation patch (see apache#1291), since query is stored in request-specific context
- "#pragma acl.graphs" preamble can be used to specify one or more graphs to restriction query exectution to - The functionality is only enabled if an access:entry for a specific user contains just <urn:jena:accessGraphsDynamic> - Only applies to SPARQL query, not GSP (since the latter can already be filtered dynamically) - Requires context propagation patch (see apache#1291), since query is stored in request-specific context
- "#pragma acl.graphs" preamble can be used to specify one or more graphs to restriction query exectution to - The functionality is only enabled if an access:entry for a specific user contains just <urn:jena:accessGraphsDynamic> - Only applies to SPARQL query, not GSP (since the latter can already be filtered dynamically) - Requires context propagation patch (see apache#1291), since query is stored in request-specific context
b4d73bd
to
62b4adc
Compare
- "#pragma acl.graphs" preamble can be used to specify one or more graphs to restriction query exectution to - The functionality is only enabled if an access:entry for a specific user contains just <urn:jena:accessGraphsDynamic> - Only applies to SPARQL query, not GSP (since the latter can already be filtered dynamically) - Requires context propagation patch (see apache#1291), since query is stored in request-specific context
- Honour context from HttpAction (as is done in SPARQLQueryProcessor parent) - Set timeouts from request (as with SPARQLQueryProcessor) - Without this, context changes configured against an endpoint are ignored if the associated dataset is an AccessControlledDataset
62b4adc
to
a1eb933
Compare
- "#pragma acl.graphs" preamble can be used to specify one or more graphs to restriction query exectution to - The functionality is only enabled if an access:entry for a specific user contains just <urn:jena:accessGraphsDynamic> - Only applies to SPARQL query, not GSP (since the latter can already be filtered dynamically) - Requires context propagation patch (see apache#1291), since query is stored in request-specific context
- "#pragma acl.graphs" preamble can be used to specify one or more graphs to restriction query exectution to - The functionality is only enabled if an access:entry for a specific user contains just <urn:jena:accessGraphsDynamic> - Only applies to SPARQL query, not GSP (since the latter can already be filtered dynamically) - Requires context propagation patch (see apache#1291), since query is stored in request-specific context
@vtermanis -- there has been a bug fixes for general context handling with queries and these are now on the main branch. I don't think it immediately relates to your report but I wanted to make sure you are working against the right state of the codebase. |
@afs thanks for the heads-up, do you mean: Is that the main one or other there others in particular? (Though it'll probably be clear when I rebase what's changed and look at the query servlet & processor code) |
What
Process request/service context in
AccessControlledDataset
the same way as is done in (parent) query processor, i.e. honour the server => dataset => endpoint context value priority order.Why
Standard SPARQL queries honour the context of the endpoint (see docs) as well as setting of reuqest-specific timeout via the
timeout
URL parameter. These two features allow one to:(See bottom of summary of example. See also mailing list thread.)
How
QueryExec
to create theQueryExecution
instead ofQueryExecutionFactory
(the latter does not considerHTTPActions
's context)timeout
parameter logic for pre-request timeouts as in base SPARQL query processorNote: I am not convinced that the way I've updated
AccessControlledDataset
(and promoted a helper method fromSPARQLQueryProcessor.java
to public) is the right way to go. But I can confirm that the following use-case works:DS1
withjena:text
indexing enabledDS2
, withAccessControlledDataset
wrappingDS1
. (The access actual rules are irrelevant here.)A
exposing a query endpoint forDS1
, with extended context:ja:context [ ja:cxtName "http://jena.apache.org/text#index" ; ja:cxtValue false ] ;
B
the same asA
, but forDS2
Current behaviour (pre-patch):
jena:text
is exposed only with query endpoint ofB
. SPARQL queries againstA
do not match text-indexed properties.Expected behaviour (post patch):
A
norB
match text-indexed properties