Support for Bearer tokens

[redmer]

I want to use Trifid with a SPARQL endpoint that uses Bearer tokens for authentication.

The suggested solution to #147 was to use fetchOptions.headers, but I can't seem to get that working anymore. And indeed, a cursory view of the code in this monorepo seems to confirm that sparql-proxy doesn't seem to be able to use generic overrides. I've tried it with the following config.yaml, adapted from the default config.yaml (trying all different places for the (fetchOptions.)headers):

Details

server:
  logLevel: debug

globals:
  datasetBaseUrl: env:DATASET_BASE_URL
  endpoints:
    default:
      url: /query
  config:
    headers:
      Authorization: env:SPARQL_ENDPOINT_TOKEN
    fetchOptions:
      headers:
        Authorization: env:SPARQL_ENDPOINT_TOKEN
  headers:
    Authorization: env:SPARQL_ENDPOINT_TOKEN
  fetchOptions:
    headers:
      Authorization: env:SPARQL_ENDPOINT_TOKEN

plugins:
  static-assets:
    module: trifid-core/plugins/static.js
    order: 0
    paths: /static-assets
    config:
      directory: file:static

  welcome:
    module: trifid-core/plugins/view.js
    paths: /
    methods: GET
    config:
      path: file:welcome.hbs

  entity-renderer:
    module: "@zazuko/trifid-entity-renderer"
    config:
      followRedirects: true
      labelLoader:
        chunkSize: 30
        concurrency: 2
        timeout: 4000

  yasgui:
    module: trifid-plugin-yasgui
    paths:
      - /sparql
      - /sparql/

  graph-explorer:
    module: trifid-plugin-graph-explorer
    paths:
      - /graph-explorer
      - /graph-explorer/
    config:
      dataLabelProperty: <http://www.w3.org/2004/02/skos/core#prefLabel>
      schemaLabelProperty: <http://www.w3.org/2004/02/skos/core#prefLabel>
      language: nl-NL
      languages:
        - code: nl-NL
          label: Dutch
        - code: nl
          label: Nederlands

  spex:
    module: trifid-plugin-spex
    paths:
      - /spex
      - /spex/

  sparql-proxy:
    module: "@zazuko/trifid-plugin-sparql-proxy"
    paths: /query
    config:
      allowRewriteToggle: true
      rewrite: false
      rewriteQuery: true
      rewriteResults: true
      endpointUrl: env:SPARQL_ENDPOINT_URL
      formats:
        ttl: "text/turtle"
        jsonld: "application/ld+json"
        xml: "application/rdf+xml"
        nt: "application/n-triples"
        trig: "application/trig"
        csv: "text/csv"
      headers:
        Authorization: env:SPARQL_ENDPOINT_TOKEN
      fetchOptions:
        headers:
          Authorization: env:SPARQL_ENDPOINT_TOKEN

and calling it with

docker run \
	-v $(PWD):/data \
	-e TRIFID_CONFIG=/data/config.yaml \
	-e SPARQL_ENDPOINT_URL=https://api.datasets.example.org/datasets/redacted/redacted/sparql \
	-e DATASET_BASE_URL=https://data.example.org/ \
	-e SPARQL_ENDPOINT_TOKEN="Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.redacted.redacted" \
	--rm -it -p 8080:8080 ghcr.io/zazuko/trifid

This configuration works as expected with a public SPARQL_ENDPOINT_URL, that requires no valid Authorization: Bearer eyJ....

[Dagdon]

Hi there,

I'm Jephthah Yohanna, a backend developer with strong experience in Node.js, and working knowledge of TypeScript and YAML. I’ve gone through this issue and I believe the problem lies in how the sparql-proxy plugin handles custom headers like the Authorization token. From what I can tell, the plugin isn’t forwarding the fetchOptions.headers as expected.

I’d be happy to take this on. I’m confident I can dig into the plugin code, trace where the headers are being dropped, and patch in proper support for Bearer tokens passed through the YAML config.

Here’s how I’d go about it:

Look through the plugin’s code to see how (or if) it reads fetchOptions.

Reproduce the issue locally using a private SPARQL endpoint.

Adjust the plugin to correctly pass headers to the fetch call.

Test it out to confirm the fix works as expected.

Submit a clean pull request with any necessary doc updates.

Looking forward to being assigned.

[ludovicm67]

I just prepared a PR for this: #735.

The new option to use would be headers.
The fetchOptions option was removed during the full rewrite of this Trifid plugin (v1 → v2).
But sending custom headers still makes sense, as in your scenario.

[ludovicm67]

I will close this as the feature is now released.
Feel free to reopen in case it is not working as expected, or open a new one in case of any related issue to that one.