Switch https://scholia-qlever.toolforge.org/ to using wikiqlever as the QLever backend

[Daniel-Mietchen]

As per

• Migration of QLever-backed Scholia to Toolforge #2766

This depends on

• Set up a copy of the current https://scholia.toolforge.org/ at https://scholia-blazegraph.toolforge.org/ #2767

[egonw]

This does not currently work. We tried that with a ~/scholia.ini (now saved as ~/scholia.ini.old): when we use the wmcloud.org, so within the allowed policy, we get a this error:

[Daniel-Mietchen]

@egonw Maybe one option here would be to set up Scholia on the same machine as the QLever endpoint it uses (i.e. wikiqlever). This way, X-Frame-Options could be set to SAMEORIGIN, and the iframes should become accessible. Of course, this would reduce the available memory even further and increase the need for a machine with more resources.

Since SAMEORIGIN only works if the full domain name is identical, we would be running into problems if we were to set up multiple wikiqlever servers and load balancing, as suggested in #2771 .

Pinging @physikerwelt .

[egonw]

It would also make it a lot harder to have multiple endpoint and load balancing

[Daniel-Mietchen]

An alternative to X-Frame-Options could be Content-Security-Policy: frame-ancestors directive, as per https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/frame-ancestors .

This would mean declaring on the wikiqlever end something like
Content-Security-Policy: frame-ancestors 'self' https://scholia-qlever.toolforge.org/

Not sure whether or what changes would be needed on the Scholia end.