Hi Raff and Council, Just briefly since I’m on vacation ;) I don’t see any security issues in relaxing CORS for the vault and the release sections (after quickly googling potential issues again). And I would very much welcome this to facilitate more app development like Raff‘s Roma! That said, I don’t want to put more pressure on Luis who’s probably some external constraints regarding those restrictions. But with our new stable home we hopefully won’t. Best Peter

Am 26.07.2019 um 20:54 schrieb Raffaele Viglianti :

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 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 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 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 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 >

---

Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council