Calling Mashup service from external web server/servlet engine
Hi,
I was trying to call the mashup service that I created from an external tomcat web server(running on port 8080) and I couldn't get through.
I was getting the following error on my mashup server:
INFO [2008-05-08 12:00:07,074] Service not dispatched
I don't see any messages on the tomcat server log.
I think the problem is in referencing the mashup that I created (named TempRetriever) from external web application.
Check out the line with javascript src tags in the attached jsp file (renamed as index.txt). I appened it with the mashup server url https://zneta:7443 to access it from external web application.
The same web application works fine if I deploy it in the embedded tomcat container without the server url above (just the relative url for both the WSRequest.js and TempRetriever stub).
So, my question is whether the mashups that I built can be accessed by external web applications or not? If it can be accessed, then what is it that I need to change in javascript src?
Please advise.
Thanks,
Kamal
| Attachment | Size |
|---|---|
| index.txt | 822 bytes |
- Login or register to post comments
- Printer friendly version
- 432 reads
Hi Kamal,Please try
Hi Kamal,
Please try ammending your function as below. You need to specify a callback function, which will process the response before calling the service. To get a good idea, you can go through the 'samples' found in your Mashup Server installation as well.
Cheers,
Tyrell
function retrieveForecast() { var input = document.getElementById('zipCode').value; alert(input); //var response; //response = TempRetriever.callMyService(input); //alert("In retrieve forecast"); //alert("response"+response); TempRetriever.callMyService.callback = function (response) { alert("response"+response); } TempRetriever.callMyService(input); }This didn't work...
Hi Tyrell,
I tried your suggestion. It didn't work. I don't know if the request is even reaching the server since I don't see any logs on the mashup server which I would generally see when I run
the client from the embedded tomcat server.
I also had a question in regards to the function changes you suggested above. I was under the impression that there is something wrong in one or both of the following two lines:
<script type="text/javascript" src="https://zneta:7443/js/wso2/WSRequest.js"></script>
<script type="text/javascript" src="https://zneta:7443/services/kshaikh/TempRetriever?stub"></script>
But, your suggestion was to add a callback handler. I don't know how adding a callback handler would solve this problem when the request is not reaching the mashup server.
If I understand callbacks right, they are used when you need asynchronous behaviour on your web page so that the part of the web page gets refreshed automatically asynchronously while the
user continues to do his/her stuff on the page.
Please let me know your thoughts.
Thanks,
Kamal
XSS strikes again?
I believe the problem is caused by Cross Site Scripting (XSS) restrictions in the browser. You're mashup server is at one location (https://zneta:7443) and your client is from another (e.g. http://localhost:8080). Browser security restrictions prevent the XMLHttp component (underlying WSRequest in the browser) from talking to the "unknown" domain. This should however give an "Access Denied" browser script error, with no error on the mashup server at all - not sure what's causing that but it sounds unrelated to me.
A common solution is to access the mashup from the jsp server instead of the browser, that is, to funnel any requests from the browser through the jsp and on to the mashup server. Code run at the server doesn't have the same XSS restrictions. There are other ways to overcome XSS in certain circumstances, but nothing easy, universal, or cross-browser. We also developed an ActiveX control/XPI plugin to provide native WSRequest support in the browser without these restrictions, but they hadn't proved very popular and have lapsed into obsolescence. Would updated versions be interesting to you?
Hi Jon...didn't see your reply before posting back to Tyrell
Hi Jon,
My mashup server and the tomcat server (not the embedded one) are located on the same physical machine (my local workstation). But, if I understand you correctly, it still gives an error because of the restrictions at the browser level.
Do you think it would make sense to call the mashup service from a servlet instead of a javascript function in a jsp page to circumvent this problem? Do you have any examples using this approach?
Also, please let me know whether the updated version of mashup server (referred in your post above) addresses this issue. What version is that?
Do you see anything wrong in the way I am referencing the mashup service from the external application (the absolute url address in the javascript include statement)? When I put the address "https://zneta:7443/services/kshaikh/TempRetriever?stub" in the browser, I see the code attached with this post. I think it is generated on the fly because even though there is no such file in the "C:\Program Files\WSO2\WSO2 Mashup Server\scripts\kshaikh" folder called"TempRetriever?stub", it still finds it when I access the url through the browser. That makes me think that the javascript includes are correct. But, I would still like to understand this better.
Thanks,
Kamal
Easiest way: use the Mashup Server's www folder.
Re the same machine - yes the browser restriction holds despite the two servers running on the same machine. The browser looks at the http scheme, domain, and port in making it's determination and it has no way of knowing that the two servers are hosted on a single (trusted) machine.
Re JSP examples - I don't have any examples handy (maybe another reader of this post does?) but I'm sure there are some in the Web Services Framework for PHP.
The next version of the mashup server won't have a general fix for the cross-scripting issue (after all it is purportedly a security feature!) But we do have some ideas on how to circumvent it using a custom client-server protocol and script injection. Not sure whether this will ever see the light of day as it starts to contradict the purpose of the Try-it, which is to provide a client for the standard protocols. I am working on a limited-scope fix for Google Gadgets that will avoid this for _some_ operations called from within an iGoogle page to an external mashup.
The easiest solution is simply to use the Mashup Server as the service host as well as the host for the client. You probably already know this, but for the TempRetriever service, you can make a folder called "www" inside the TempRetriever.resources folder, and any files in this folder will be served up as https://zneta:7443/services/kshaikh/TempRetriever/. E.g. that link would serve up a page named index.html. (Index.html is the default filename for the directory, and the presence of the file also activates a link to the UI on the mashup's main page.) Or a graphic named graphic.jpg can be accessed from https://zneta:7443/services/kshaikh/TempRetriever/graphic.jpg. I believe you can even add .jsp files to this folder and they will be honored (can't remember trying this myself though.) Since the UI links and the service endpoints come from the same domain, there are no XSS issues.
Another option is to deploy a proxy under your Web Server, which rewrites the request URLs and forwards them on to the Mashup Server domain. Again I haven't done this myself, opting so far for the "www" solution. But perhaps this is an addon we should develop and make available...
What qualities are you looking for in a separate web server host that aren't available in the Mashup Server?
Mashup as aggregator
Hi Jon
Here's what I am looking for from an architectural standpoint:
1. aggregate/compose existing services using mashup to create new services
2. Expose new mashup services created above as WSDL (I haven't published the mashup services as Web services yet but I assume it's possible to do this using mashup server.)
3. Consume the mashup web services created above from any client (client could be cross platform like .NET or other devices)
I guess I was trying no. 3 above directly interfacing with no. 1. Maybe if I access no. 1 above via no.2 then this won't be an issue at all.
Let me know your thoughts and if what I stated above makes sense to you.
Thanks,
Kamal
Perfect fit ;-)
I think we have a great fit for those qualities:
1) Javascript logic for aggregating services (Web Services, feeds, Web pages, data sources, etc.) into a new service.
2) Each Javascript function is automatically exposed as a new Web Service, with WSDL 1.1, WSDL 2.0, XSD descriptions, bindings for SOAP 1.1, SOAP 1.2, XML over HTTP (each over http: or https:), plus a JSON option. We have the ability to plug in any of the other bindings supported by WSO2 products as well - JMS, etc. Web services are our core competency as a company.
3) These Web services are interoperable from a large variety of platforms, both ones that we provide (check out our frameworks for Java, Spring, PHP, Perl, C (the list is long and continues to grow), and cross platform - e.g. we do lots of public and private interop work with .NET clients. These environments don't generally have security restrictions like the browser enforces.
If you're just doing a proof of concept, I'd recommend using either the "www" folder to avoid XSS issues, or if you're on Windows you can try launching the HTML in IE from the file system instead of from a Web Server. IIRC IE doesn't enforce the security restrictions in this case (as it assumes you already have full file system access ;-). If you are planning on providing a web page to end users, accessing the actual mashup server from JSP, perhaps using the Web Service Framework for Java, would be a good plan. There's also a rumor that we've got a proxy under development that you could deploy to route local requests to the Mashup Server. If you're interested in that in the longer term I can check out it's status.
Hope this helps!
It worked with IE!!!
Hi Jon,
Thanks for your reply. I tried the same url with IE browser and it worked fine. Earlier I was testing with firefox and I was having the issue with browser security as you explained above.
I dont think I would need to go through a proxy approach if I publish the mashup as a web service and call it from the external client through a WSDL using a web service framework.
Once again, thanks for your help.
Kamal