<div dir="ltr"><div><div><div><div>The open proxy has been implemented a lot here in the Netherlands back in the days when "the internet was a safe place".<br><br></div>I recently notified the security officer of a large governemental body of this issue as I think handing out wildcards to use your servers as a proxy is a no-go. He is looking into the problem.<br>

<br></div>In my opinion, a better solution would be CORS (<a href="http://en.wikipedia.org/wiki/Cross-origin_resource_sharing">http://en.wikipedia.org/wiki/Cross-origin_resource_sharing</a>) but this would mean that the (open) dataproviders will need some sort of policy to allow applications access. I do however think thats the least-worse way to go, or the data providers would have to set up a key validation mechanism.<br>

<br></div>Anyway, knowing who are consuming your services is not a bad thing. Neither is telling a service provider that you are going to consume their service.<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

2013/12/17 Phil Scadden <span dir="ltr"><<a href="mailto:p.scadden@gns.cri.nz" target="_blank">p.scadden@gns.cri.nz</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Anyway the decision is not mine, I have to provide a working web client bringing the functionality of modify features, so I need a WFS-t in the backend. Moreover I need to provide a wfs-t accessible without a proxy for architecture reasons since the web browser and the web server will be embebbed in a C++ standalone application and we cannot modify the web server to host  a proxy.<br>


</blockquote>
<br>
The need for a proxy is dictated by security features of the browser. Most browsers will not do cross-domain XHR for very very good reasons. Its a pretty strange server that cant host a proxy. What is the servlet container that hosts your the WFS server?(and why cant the proxy live in that?). If the only WFS features you are dealing are hosted on embedded server, then you may be able to configure so request is not cross-domain. Might also depend on what exactly this embedded web browser actually is. The alternative would be protocol.script but you will be writing a lot of code to work around its limitations. Effective web apps work to principle of having the server do most of the computing so I am curious as to how serverside works for your application.  I would have to say that using embedded web-server and browser + OL for a standalone C# mapping application is a pretty strange choice. OL has to work around web limitations that simply dont exist to a standalone C# application.<br>


<br>
Notice: This email and any attachments are confidential.<br>
If received in error please destroy and immediately notify us.<br>
Do not copy or disclose the contents.<br>
<br>
______________________________<u></u>_________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.osgeo.org" target="_blank">Users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/openlayers-users" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/openlayers-<u></u>users</a><br>
</blockquote></div><br></div>