<div dir="ltr">Hey Chris,<div><br></div><div>sorry, quick replies:</div><div><br></div><div>- EPrints' own documentation states that one can modify objects via /id/ ('CRUD') - see <a href="https://github.com/eprints/eprints/blob/3.3/perl_lib/EPrints/Apache/CRUD.pm">https://github.com/eprints/eprints/blob/3.3/perl_lib/EPrints/Apache/CRUD.pm</a><br></div><div><br></div><div>- you could always protect from POST, PUT, DELETE at the webserver level if you had to</div><div><br></div><div>- 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)<br></div><div><br></div><div>- 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 :-)<br></div><div><br></div><div>Seb</div><div><br></div><div>PS: i'm a little (lot) rusty too :-)</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 22, 2017 at 2:58 PM, Christopher Gutteridge <span dir="ltr"><<a href="mailto:cjg@ecs.soton.ac.uk" target="_blank">cjg@ecs.soton.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, a bit odd me asking a question but I'm a bit rusty.<br>
<br>
We've a request from a (non malicious) third party to allow CORS so they<br>
can have javascript that accesses /id/ and /cgi/export/ to do clever things.<br>
<br>
If there's any way to alter the system via these URLs it's a<br>
cross-site-scripting no-no, and from reviewing the code I *think* that<br>
those URLs are always read-only.<br>
<br>
I thought the REST interface was at /rest/ but it looks like there's<br>
another one implemented on /id/<br>
<br>
<a href="https://github.com/eprints/eprints/blob/3.3/perl_lib/EPrints/Apache/REST.pm" rel="noreferrer" target="_blank">https://github.com/eprints/<wbr>eprints/blob/3.3/perl_lib/<wbr>EPrints/Apache/REST.pm</a><br>
-- uses /rest/<br>
<a href="https://github.com/eprints/eprints/blob/3.3/perl_lib/EPrints/Apache/CRUD.pm" rel="noreferrer" target="_blank">https://github.com/eprints/<wbr>eprints/blob/3.3/perl_lib/<wbr>EPrints/Apache/CRUD.pm</a><br>
-- uses /id/<br>
<br>
I suspect that means that it *is* too dangerous to allow cross site JS<br>
to connect to /id/ which is a pity, but security first, right?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<br>
Christopher Gutteridge -- <a href="http://users.ecs.soton.ac.uk/cjg" rel="noreferrer" target="_blank">http://users.ecs.soton.ac.uk/<wbr>cjg</a><br>
<br>
University of Southampton Open Data Service: <a href="http://data.southampton.ac.uk/" rel="noreferrer" target="_blank">http://data.southampton.ac.uk/</a><br>
You should read our Web & Data Innovation blog: <a href="http://blogs.ecs.soton.ac.uk/webteam/" rel="noreferrer" target="_blank">http://blogs.ecs.soton.ac.uk/<wbr>webteam/</a><br>
<br>
*** Options: <a href="http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech" rel="noreferrer" target="_blank">http://mailman.ecs.soton.ac.<wbr>uk/mailman/listinfo/eprints-<wbr>tech</a><br>
*** Archive: <a href="http://www.eprints.org/tech.php/" rel="noreferrer" target="_blank">http://www.eprints.org/tech.<wbr>php/</a><br>
*** EPrints community wiki: <a href="http://wiki.eprints.org/" rel="noreferrer" target="_blank">http://wiki.eprints.org/</a><br>
*** EPrints developers Forum: <a href="http://forum.eprints.org/" rel="noreferrer" target="_blank">http://forum.eprints.org/</a><br>
</font></span></blockquote></div><br></div>