q: Could the proxy page be replaced by any standard asp.net (mvc) or j2ee application ?
---- desc We would like to get control of all requests being issued by the client API. This mean all of the map requests (to get tiles, given the example) and also other requests that might appear. I need to get them channeled though our web application sitting somewhere on the server (let's assume both technologies, ASP.NET (MVC?) and/or JAVA J2EE), where I need the power to decide what to do with the request, either allow it to get data from the REST / SOAP service, or block them, or just modify them based on the user privileges we have set somewhere in our configuration db schema.
Setting the proxy page (as per here) could be something we need.
My question is: 1) could be (technically) the provided proxy page (can be downloaded from the link I've posted above), replaced with full web application (either classic ASP.NET, or ASP MVC) ??? 2) is there any other way I could force all of the request to be channeled through my server application/service?
I've also seen an article here: Less Chatter, More Work. What's interesting is the Figure n.3. below in the description it says : "In this architecture, the user map click initiates a call to a well-known resource URI (http://mysamplewebsite/roadInfo/get or http://mywebsite/lineclipper, etc.) on the Web server." That's on the click, but how about the map widget and its requests for the tiles... can I handle them?
Thanks for the insight. I'd really appreciate any help here. Seems like we need to switch on the REST train as the WebADF is going to be deprecated soon, no matter now on how good your application is/was.
According to that link: "A proxy page is necessary in the following situations:"
1. The application creates requests that exceed 2048 characters. 2. The application uses a service that is secured with token-based authentication 3. The application edits features in a feature service, unless the application is on the same domain as the GIS Server
Number 2 seems to be the point of issue. Further down in that link, "3. Secure the Web application"
If you use the proxy page and don't "Require users of the application to login (authenticate) in order to use the application", then there is no point in having the proxy page at all because the proxy page will let anyone in that knows the URL to the proxy page.
This approach doesn't seem very feasible for a public website. If ESRI requires us to go this far, you could control authentication via the web server and block any access by domain, etc, to your web service URL that is not approved and forget the proxy page, unless you need either #1 or #3 mentioned above.
