CentreForDigitalHumanities / CentreForDigitalHumanities/Textcavator

Embedding Textcavator without a separate server

Open
#1,956 1 comment 0 reactions 0 assignees View on GitHub
affects-deployment code quality
Dominant language
Python
Stars
12
Forks
3
Avg merge
3d 3m
Merged PRs (30d)
9

Description

PEACE portal uses an iframe to display the Textcavator search interface for a corpus in a wordpress site. To do this, we run a separate server just for PEACE portal, which is configured differently for the sake of embedding.

The setup works, but running a separate server increases the maintenance cost. We're currently looking into using a similar setup for another project, and I would like to avoid making yet another Textcavator server. (See also #1955)

For context, PEACE portal originally used a different server and a forked source repository to enable some more fundamental changes, such as not requiring login. At the moment, the differences between PEACE portal and our main server are largely superficial, so it seems doable to run all this from a single server - either here or in similar cases in the future.

There are two approaches to integrate the servers:
1. Make the PEACE portal corpus a public corpus on our main server, and use that URL for the iframe on the wordpress site. The corpus would also be visible when you visit the Textcavator site, which may be a positive or a negative.
2. Use the Sites framework (#1955) and keep providing a separate domain for PEACE portal. This would allow us to exclude the corpus from our main site. Might also make it easier to use separate settings for this project, but this may not be necessary.

I'm trying to get an overview of what is different between the servers, but I did not work on this project. Here is what I can list:

- Visibility of the PEACE portal corpus. See above.
- Request headers: [X-FRAME-OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Frame-Options) / [CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy). Our default setting does not allow iframe embedding. (I don't know the exact configuration on peace portal.)
- The header and footer are hidden based on an environment setting. This could also be controlled with a query parameter or with [window.parent](https://developer.mozilla.org/en-US/docs/Web/API/Window/parent).
- Direct download limits are higher on PEACE portal, to benefit users without an account. Possible solutions:
- With approach 1: [Set download limits per corpus](https://github.com/CentreForDigitalHumanities/Textcavator/discussions/1437)
- With approach 1: add the instruction to go to textcavator (and create an account there) for big downloads.
- With approach 2: set download limits per site.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by comparing the PEACE portal server with the main server, focusing on the differences listed in the issue: corpus visibility, iframe-related headers, header and footer visibility, and download limits. Review #1955 and the two proposed integration approaches. Done means one server can support the PEACE portal setup without requiring another separately maintained Textcavator server.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.