Please pass configured settings for request headers to all AJAX requests.

[elasticjava]

Working with secured SPARQL Endpoints I cannot pass authentication and request headers to all used requests.

In particular, the autocompletewidget uses its own AJAX requests, which do not inherit the configured properties of the Yasqe configuration.

It would be great if the Yasqe configuration could also be done via Typescript.

From a certain size of the created combined SPARQL query GET request are unsuitable.
So it would be great if that could be configurable as well.

[tfrancart]

Yes I agree. This was registered as an issue in #187 .
I don't have yet a clear idea on what would be the best architecture for this.

[SteinerPascal]

@tfrancart should i add an option to adapt the datasource property? From
"datasource": "datasources:list_rdfslabel_alpha_with_count",
To:

"datasources": {
    "labelProperty" : "http://www.w3.org/2000/01/rdf-schema#label",
    "sparqlEndpointUrl" : "http://non-default-endpoint.com",
    "queryTemplate":"list_rdfslabel_alpha_with_count",
    "method":"POST",
    "auth":{
    "scheme":"basic",
    "parameters": [
        "credentials": "YWxhZGRpbjpvcGVuc2VzYW1l"
      ]
  }

or for digest auth:

"datasources": {
    "labelProperty" : "http://www.w3.org/2000/01/rdf-schema#label",
    "sparqlEndpointUrl" : "http://non-default-endpoint.com",
    "queryTemplate":"list_rdfslabel_alpha_with_count",
    "method":"POST",
    "auth":{
    "scheme":"digest",
    "parameters": [
        "realm": "<realm>",
        " uri":"<url>",
        "algorithm":"<algorithm>",
        "etc": "..."
      ]
 }

Advantages:

• Allows to define a different auth for different datasources.
• flexible to adjust for other kinds oth auths
• All datasource options are in one place

Disadvantages:

• Credentials need to be known beforehand or otherwise sparnatural config needs to be adapted and sparnatural restarted.
• Not easily synchronizable with Yasqe

[tfrancart]

Salut @SteinerPascal

@tfrancart should i add an option to adapt the datasource property?

I don't think this should belong to the configuration. The configuration is meant to be "purely" semantic, with the definitions and mappings to classes and properties - and to queries to populate the lists. But the gory auth details of how to authenticate to SPARQL endpoints belong to another level. Typically you can have an ontologist designing the config, and a programmer or devops configuring the auth details.

Besides, this can be easily written in JSON but doing it in OWL (or future SHACL) config would require creating corresponding properties in the config-core or config-datasources ontologies.

What I suggest is to instead pass it as a pure JSON object to Sparnatural, as a map of endpoint/options, something like:

{
  "http://non-default-endpoint.com" : {
    "method":"POST",
    "auth":{
      "scheme":"digest",
      "parameters": [
        "realm": "<realm>",
        " uri":"<url>",
        "algorithm":"<algorithm>",
        "etc": "..."
      ]
  },
 "http://another-endpoint.com" : {
    // other configs for another endpoint
  }
}

I don't know if it is possible, but we could use exactly the same structure as for YasQE, so that the same config object can be used for both (?)

Then, when issuing queries, we can use the options provided to issue the request, like at

Sparnatural/src/sparnatural/components/widgets/listwidget/ListWidget.ts

Line 80 in ba13bd9

let init = {

So - pretty much what you propose, but not in the config and passed as pure technical parameters to the Sparnatural element.

[tfrancart]

Done in #517

[tfrancart]

This is now done. The only place where headers are not passed is the initial call to load the configuration file (see #529 )