How can I consume a webservice that hasn't explicitely created a crossdomain.xml?
I understand it's for security and to prevent cross-site scripting, but it does seem like a major limitation to the Flex framework.
For example, if I want to consume a webservice, which is suppose to be language agnostic, then I can't with Flex. The webservice/server has to be specifically prepared for Flex/Flash. If it's not, then it cannot be consumed.
That can't be right can it?
Use a proxy server like Apache or BlazeDS to forward requests from the host the SWF originated from to the host with the web services.
If your webservice is on another domain, you'll need a crossdomain file. Pure and simple.
I have found two ways around this:
Use an HTTPService
Use external interface calls to Javascript embedded on your flash file's container page, which will then call the web service
Option 2 is more complex, but I prefer it. This link should help you out with the ExternalInterface class: http://blog.flexexamples.com/2008/03/11/returning-values-from-javascript-in-your-flex-applications-using-the-externalinterface-api/#more-555
What I did was "put a middle man". So basically, I put a php script that reads from the other side what I need. Yes, unfortunately, that requires a "server". You could try a JavaScript as well.
Related
I want to use HTTP methods (GET/PUT/POST/DELETE) with an Azure resource and even have the URIs to do so. I understand that this practice utilizes RESTful web services.
What file type or programming language do I use to call these? On every documentation site that I have found, the only thing I see is something like the following, without any context:
Method Request URI
POST https://media.windows.net/api/Channels(‘*channelid*’)/Stop
So, where do I include this? HTML? C#? Do I create an ASP.NET web app and place it somewhere in there?
This would be very helpful to know so that I can utilize these methods!
You can use any programming language that has http support, or indeed your browser (most have native support to alter requests).
A more convenient alternative to test the api might be a rest client, a popular one being postman, a browser plugin.
We've recently been working on a fairly modern web app and are ready to being deploying it for alpha/beta and getting some real-world experience with it.
We have ASP.Net based web services (Web Api) and a JavaScript front-end which is 100% client-side MVC using backbone.
We have purchased our domain name, and for the sake of this question our deployment looks like this:
webservices.mydomain.com (Webservices)
mydomain.com (JavaScript front-end)
If the JavaScript attempts to talk to the webservices on the sub-domain we blow up with cross domain issues, I've played around with CORS but am not satisfied with the cross browser support so I'm counting this out as an option.
On our development PC's we have used an IIS reverse proxy to forward all requests to mydomain.com/webservices to webservices.mydomain.com - Which solves all our problems as the browser thinks everything is on the same domain.
So my question is, in a public deployment, how is this issue most commonly solved? Is a reverse proxy the right way to do it? If so is there any hosted services that offer a reverse proxy for this situation? Are there better ways of deploying this?
I want to use CloudFront CDN as all our servers/services are hosted with Amazon, I'm really struggling to find info on if a CDN can support this type of setup though.
Thanks
What you are trying to do is cross-subdomain calls, and not entirely cross-domain.
That are tricks for that: http://www.tomhoppe.com/index.php/2008/03/cross-sub-domain-javascript-ajax-iframe-etc/
As asked how this issue is most commonly solved. My answer is: this issue is commonly AVOIDED. In real world you would setup your domains such as you don't need to make such ways around just to get your application running or setup a proxy server to forward the calls for you. JSONP is also a hack-ish solution.
To allow this Web Service to be called from script, using ASP.NET AJAX, add the following line to the first web service code-behind :
[System.Web.Script.Services.ScriptService]
You can simply use JSONP for AJAX requests then cross-domain is not an issue.
If AJAX requests return some HTML, it can be escaped into a JSON string.
The second one is a little bit awkward, though.
You have 2/3 layers
in the web service code-behin class, add this atribute : <System.Web.Script.Services.ScriptService()> _
maybe you need to add this in the System.web node of your web.config:
<webServices>
<protocols>
<add name="AnyHttpSoap"/>
<add name="HttpPost"/>
<add name="HttpGet"/>
</protocols>
</webServices>
In the client-side interface
-Add web reference to the service on the subdomain (exmpl. webservices.mydomain.com/svc.asmx)
Visual studio make the "proxy class"
-add functionality in the masterpage's|page's|control's code behin
-Simply call this functions from client-side
You can use AJAX functionality with scriptmanager or use another system like JQuery.
If your main website is compiled in .NET 3.5 or older, you need to add a reference to the namespace System.Web.Extensions and declare it in your web.config file.
If you have the bandwidth (network I/O and CPU) to handle this, a reverse proxy is an excellent solution. A good reverse proxy will even cache static calls to help mitigate the network delay introduced by the proxy.
The other option is to setup the proper cross domain policy files and/or headers. Doing this in some cloud providers can be hard or even impossible. I recently ran into issues with font files and IE not being happy with cross domain calls. We could not get the cloud storage provider we were using to set the correct headers, so we hosted them locally rather than have to deal with a reverse proxy.
easyXDM is a cross domain Javascript plugin that may be worth exploring. It makes use of standards when the browser supports them, and abstracts away the various hacks required when the browser doesn't support the standards. From easyXDM.net:
easyXDM is a Javascript library that enables you as a developer to
easily work around the limitation set in place by the Same Origin
Policy, in turn making it easy to communicate and expose javascript
API’s across domain boundaries.
At the core easyXDM provides a transport stack capable of passing
string based messages between two windows, a consumer (the main
document) and a provider (a document included using an iframe). It
does this by using one of several available techniques, always
selecting the most efficient one for the current browser. For all
implementations the transport stack offers bi-directionality,
reliability, queueing and sender-verification.
One of the goals of easyXDM is to support all browsers that are in
common use, and to provide the same features for all. One of the
strategies for reaching this is to follow defined standards, plus
using feature detection to assure the use of the most efficient one.
To quote easy XDM's author:
...sites like LinkedIn, Twitter and Disqus as well as applications run
by Nokia and others have built their applications on top of the
messaging framework provided by easyXDM.
So easyXDM is clearly not some poxy hack, but I admit its a big dependency to take on your project.
The current state of the web is that if you want to push the envelop, you have to use feature detection and polyfills, or simply force your users to upgrade to an HTML5 browser. If that makes you squirm, you're not alone, but the polyfills are a kind of temporary evil needed to get from where the web is to where we'd like it to be.
See also this SO question.
I use the ASP.Net ScriptManager to load the scripts needed for calling WCF services via HTTP/JSON. I am optimizing the total size of my pages (including scripts) and I see that Microsoft's AJAX library is the biggest file that I have at 96KB. Is there anyway that I can get a version of this file with just the features I need loaded?
Or since I already have jquery, should I use that to call my WCF JSON service instead?
Cheers,
Jon
WCF JSON services degrade gracefully down to working as a standard webservice, so you should have no problems using jQuery to post and retrieve data from them. You may lose some of the integration bells and whistles, but as someone who has taken the path you're suggesting, I can say that I don't miss it at all.
The only problem might be if you're using advanced WCF feature like 2 way connections, or guaranteed connections.
Does anyone know of a good article or tutorial on the Internet demonstrating the use of GWT leveraging a (ASP.NET) web service cross domain?
To my knowledge, interacting with either XML or JSON should be possible from GWT, but becomes a lot more difficult when the web service is on a different domain. I've tried finding an article that demonstrates this setup, but without any luck.
There are a few options available:
use the Cross Site linker - it should make cross domain request easier, simply add <set-linker name="xs"/> in your module file (*.gwt.xml)
window.name hack :) Be sure to read the post with the original dojo proposal
JSONP
many others ;)
But first I recommend reading http://code.google.com/webtoolkit/tutorials/1.6/Xsite.html - it should get you going :)
I was initially going for a JSONP approach (as suggested by Google), in order to do cross site AJAX calls in JavaScript, but ended up with too many hacks that I had to incorporate into the ASP.NET web service in order for it to work.
The solution, in my case, was instead to use GWT RPC to a JAVA servlet, acting as a proxy, which then would call the ASP.NET Web Service using SOAP. The SOAP Java classes was generated using the wslist tool that is part of JAX-WS project (as demonstrated here).
Using the GWT RPC, I was still able to call the JAVA servlet asynchronously, giving the user a seamless experience.
I have a handful of ASP.NET websites which communicate with different instances of SQL Server 2005 via a web reference to the report server's web service. However, today I toyed with the notion of using the WSDL tool to create a proxy class from one of the SQL Server instances and, in turn, using the proxy to create a dll (before doing so, I modified the proxy's constructor to accept a URL - so that I could point the proxy to any of the web service instances).
I'm pretty sure that the web service should be pretty, if not completely, static, in terms of updates. So, my question is: are there any drawbacks for using the compiled proxy class (in the bin directory), as opposed to using the proxy class (auto-generated), itself? If not, what are some motivations for going one way or the other?
As to my knowledge, there is absolutely no difference between both of them. The Service Reference does exactly what the svcutil also does, but allows the user to do it in an easier way. Service Reference is just a warpper around the svcutil.exe and it does nothing more than what the basic svcutil.exe does.
Thanks