-
Notifications
You must be signed in to change notification settings - Fork 3
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
Support a parameter to make access rewrites fatal #51
Comments
Could you explain what an access rewrite here means? Kustvakt maintains access rewrite by setting a set of availability constraints to the corpus query with respect to the granted user access. Typically this is added to any search query, except when it includes a corpus query with a proper availability set. For instance the following URL contains the required availability constraint, thus access rewrite is not performed: https://korap.ids-mannheim.de/api/v1.0/search?q=Monnemer&ql=poliqarp&fields=textSigle,title,availability&cq=availability+%3D+%2FCC-BY.*%2F |
The goal of this parameter would be to optionally make unnoticed access rewrites and corresponding result artifacts in API client script queries 100% impossible. It will typically be used together with |
But there can't be rewrites, when they are disabled ... 😕 |
When |
For
I agree. Although this is not implemented because there are no non-public fields at the moment. |
What is the reasoning behind that? |
For a simple query like: https://korap.ids-mannheim.de/api/v1.0/search?q=Monnemer&ql=poliqarp&fields=textSigle,title,availability&access-rewrite-disabled=true Availability fields have to be set to get all allowed resources. I think there might be resources containing availability fields that may not be allowed. When the URL contains a corpus query with inadequate availability fields, such an access rewrite is also required. For instance: |
I would expect that |
The parameter name is maybe misleading. The implementation was to enable public metadata request. |
But what is the reasoning for the rewrite? |
As I described above. But I think you are right, for the second case, there shouldn't be any rewrite. I am not sure for the first case. Is there no other licenses that are not covered by |
These are DeReKo/i5 specific license fields. I guess we said we wanted them added for logged in users so we can explicitely exclude private corpora. |
You mean private corpora other than DeReKo/i5? And this is allowed for public metadata requests? |
I think so. Otherwise the parameter should definitely be renamed. But as this is a license question, we should ask @kupietz . |
Currently when an access rewrite occurs and a client does not check for rewrites, the changes to the underlying corpus resource of a query are easily missed and not taken into account by the user. To make catching these mistakes easier, a parameter like
access-rewrite-fatal
may be introduced to all access rewriting endpoints that will return a failure code instead of results whenever an access rewrite occurred.This feature was suggested by @kupietz
The text was updated successfully, but these errors were encountered: