The open proxy has been implemented a lot here in the Netherlands back in the days when "the internet was a safe place".
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. In my opinion, a better solution would be CORS ( http://en.wikipedia.org/wiki/Cross-origin_resource_sharing) 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. 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. 2013/12/17 Phil Scadden <[email protected]> > > 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. >> > > 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. > > Notice: This email and any attachments are confidential. > If received in error please destroy and immediately notify us. > Do not copy or disclose the contents. > > _______________________________________________ > Users mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/openlayers-users >
_______________________________________________ Users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/openlayers-users
