I think, for now, the benefits of enabling a demo for one external researcher/developer do not outweigh having to do nuanced security. It means I can close the task, which is helpful.

Hey Chris,

sorry, quick replies:

- EPrints' own documentation states that one can modify objects via /id/ ('CRUD') - see https://github.com/eprints/eprints/blob/3.3/perl_lib/EPrints/Apache/CRUD.pm

- you could always protect from POST, PUT, DELETE at the webserver level if you had to

- your third party can route their JS calls via their own local (cgi-like) script that could do the http requests to EPrints' /id/ endpoint behind-the-scenes, bypassing CORS altogether (assuming that these guys don't rely on cookies being passed through - i don't know the exact details of their project so ignore if not relevant)

- to me, "security first" is more like how the rest of the site should be protected against XSS - not disabling useful endpoints  which are there for the exact purpose you're describing here :-)

Seb

PS: i'm a little (lot) rusty too :-)

On Tue, Aug 22, 2017 at 2:58 PM, Christopher Gutteridge <cjg@ecs.soton.ac.uk> wrote:

Hi, a bit odd me asking a question but I'm a bit rusty.

We've a request from a (non malicious) third party to allow CORS so they
can have _javascript_ that accesses /id/ and /cgi/export/ to do clever things.

If there's any way to alter the system via these URLs it's a
cross-site-scripting no-no, and from reviewing the code I *think* that
those URLs are always read-only.

I thought the REST interface was at /rest/ but it looks like there's
another one implemented on /id/

https://github.com/eprints/eprints/blob/3.3/perl_lib/EPrints/Apache/REST.pm
-- uses /rest/
https://github.com/eprints/eprints/blob/3.3/perl_lib/EPrints/Apache/CRUD.pm
-- uses /id/

I suspect that means that it *is* too dangerous to allow cross site JS
to connect to /id/ which is a pity, but security first, right?

--

Christopher Gutteridge -- http://users.ecs.soton.ac.uk/cjg

University of Southampton Open Data Service: http://data.southampton.ac.uk/
You should read our Web & Data Innovation blog: http://blogs.ecs.soton.ac.uk/webteam/

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/

-- 
Christopher Gutteridge -- http://users.ecs.soton.ac.uk/cjg

University of Southampton Open Data Service: http://data.southampton.ac.uk/
You should read our Web & Data Innovation blog: http://blogs.ecs.soton.ac.uk/webteam/