This security constraint looks really quite odd. In my case, and I think it's a quite general scenario, I don't know the final urls, so I cannot configure destinations as described above.
The business case: I'm writting a mobile app to access SharePoint by using webservices. SharePoint allows a lot of sites and subsites. Each site has its own url to access from browsers and other to access from webservices.
Example:
and companies can have a lot of sites and subsites. So, the SharePoint administrator should synchronize the proxy-config.xml file in order to provide access to all the SharePoint sites from BlazeDS. It's even worst when you devlop a generic product and you know nothing about the urls of your customers. Will you provide instructions to all Windows administratos to configure BlazeDS???
In the cases described above, urls must be dynamic. But DlazeDS does not allow them whether they require remote authentication. It's simply absurd. Furthermore, BlazeDS becomes contradictory: If you use dynamic urls (any), BlazeDS requires protect destinations by using server authentication at proxy level (Tomcat, for example). After, BlazeDS denies access to them because they require remote authentication (SharePoint, for example). Has it sense?
Regarding my particular case: End urls (SharePoint) are protected by authentication (Windows NTLM). BlazeDS proxy is also protected by authentication (mandatory to use dynamic urls). And I've removed the bizarre security constraint from BlazeDS source code in order to allow to use dymanic urls requiring remote authentication.... and it works. Now, my app can connect to any url introduced at real time, without configuring destinatons in any BlazeDS file. i don't see how it can compromise security becase users must authenticate in two servers (proxy+remote) prior to access any data. Of course, proxy authentication is managed by the app in order to keep things as much simple as possible for end users.
Regards,
Pablo.
