[EP-tech] Question about CORS

[Christopher Gutteridge]

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.


On 22/08/2017 15:57, Sébastien François wrote:
> 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 at ecs.soton.ac.uk <mailto:cjg at 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
>     <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
>     <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
>     <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/
>     <http://blogs.ecs.soton.ac.uk/webteam/>
>
>     *** Options:
>     http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
>     <http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech>
>     *** Archive: http://www.eprints.org/tech.php/
>     <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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20170822/606e9826/attachment.html