Thanks Luis, I'm glad you were able to figure something out! I just tested and it all seems to be working. All the best, Raff On Fri, Jul 26, 2019 at 4:05 PM Luis Meneses wrote:

Hi Raff,

I found a way to enable it without impacting security. You should be good to go.

Cheers, ----- -Luis

On Jul 26, 2019, at 11:54 AM, Raffaele Viglianti < raffaeleviglianti@gmail.com> wrote:

Hi Luis,

Any more thoughts on this? (Or from other council members?) For the time being I'm switching to https://vault.tei-c.de which enables CORS for all domains.

Raff

On Wed, Jul 24, 2019 at 1:28 PM Raffaele Viglianti < raffaeleviglianti@gmail.com> wrote:

...

Hi Luis,

Looping in the council list again.

Why does it sound like a bad idea? What are your concerns and how could we address them while allowing full access to static data?

One way could be making sure the header is only added to the /Vault location in Apache or Nginx.

Raff

On Wed, Jul 24, 2019, 1:06 PM Luis Meneses wrote:

...

Hi Raff,

Enabling CORS for all sites does sound like a bad idea. I can set a rule to allow it for some sites, but now all of them.

Is this something that we can try to do?

Best, ----- -Luis

On Jul 24, 2019, at 7:10 AM, Raffaele Viglianti < raffaeleviglianti@gmail.com> wrote:

Hi Luis,

We had CORS allowed from all domains before and the Council saw that as a good idea. We should make it as simple as possible to obtain static files from the Vault. I don't believe this will expose the server to any new forms of attacks because this would simply allow GET requests of static files from a browser JavaScript source. Since any other system can already send unlimited requests of this type, limiting JavaScript does not make the server more secure. In other words, the JavaScript won't be interacting with an API, but simply GETting static files, so there shouldn't be any risk involved in turning CORS on.

Thanks, Raff

On Tue, Jul 23, 2019 at 6:45 PM Luis Meneses wrote:

...

Hi Raff,

Would it be sufficient to allow requests from a smaller set of domains?

For example: roma2.tei-c.org where the Roma tool lives?

Making the other change can introduce some new attack vectors for the site.

Best, ----- -Luis

On Jul 22, 2019, at 6:28 AM, Raffaele Viglianti < raffaeleviglianti@gmail.com> wrote:

Hi Luis,

Thanks for the quick reply! The idea is that the server that serves the data from tei-c.org/Vault needs to add the Access-Control-Allow-Origin to the response so that browsers know they're allowed to grab data from different domains. If the server is Apache, it should enough to add the line below to <VirtualHost> or <Location> (depending on the set up)

Header set Access-Control-Allow-Origin "*"

If the server is nginx, you should add this under the right location stanza;

add_header 'Access-Control-Allow-Origin' '*';

Let me know if I can help further, and thanks! Raff

On Sun, Jul 21, 2019 at 10:12 PM Luis Meneses wrote:

...

Hi Raff,

Sorry to hear about that you have an issue. Can you give me more details on it?

I am just not too sure about what I need to do to fix it.

Best, -Luis

On Jul 21, 2019, at 1:02 PM, Raffaele Viglianti < raffaeleviglianti@gmail.com> wrote:

Dear Luis,

Sorry to add even more to your plate, but could you enable CORS on the TEI Vault? The new version of Roma written in JavaScript needs it to access ODD customizations and p5subet. Example: fetch https://tei-c.org/Vault/P5/current/xml/tei/odd/p5subset.json The response needs to contain the header Access-Control-Allow-Origin: *

Thanks! Raff