<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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.<br>
</p>
<br>
<div class="moz-cite-prefix">On 22/08/2017 15:57, Sébastien François
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:EMEW3|f8e2376d4f60b9e33c5072f2d4d1fe48y7LG7L14eprints-tech-bounces|ecs.soton.ac.uk|CAHpQg=cbKAPNWxBYzBefS9=La4BuEa=KZ0DW2rBOJdmwpJb78w@mail.gmail.com">
<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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">http://www.eprints.org/tech.<wbr>php/</a><br>
*** EPrints community wiki: <a
href="http://wiki.eprints.org/" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://wiki.eprints.org/</a><br>
*** EPrints developers Forum: <a
href="http://forum.eprints.org/" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://forum.eprints.org/</a><br>
</font></span></blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">*** Options: <a class="moz-txt-link-freetext" href="http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech">http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech</a>
*** Archive: <a class="moz-txt-link-freetext" href="http://www.eprints.org/tech.php/">http://www.eprints.org/tech.php/</a>
*** EPrints community wiki: <a class="moz-txt-link-freetext" href="http://wiki.eprints.org/">http://wiki.eprints.org/</a>
*** EPrints developers Forum: <a class="moz-txt-link-freetext" href="http://forum.eprints.org/">http://forum.eprints.org/</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Christopher Gutteridge -- <a class="moz-txt-link-freetext" href="http://users.ecs.soton.ac.uk/cjg">http://users.ecs.soton.ac.uk/cjg</a>
University of Southampton Open Data Service: <a class="moz-txt-link-freetext" href="http://data.southampton.ac.uk/">http://data.southampton.ac.uk/</a>
You should read our Web & Data Innovation blog: <a class="moz-txt-link-freetext" href="http://blogs.ecs.soton.ac.uk/webteam/">http://blogs.ecs.soton.ac.uk/webteam/</a>
</pre>
</body>
</html>