[wsas-java-dev] Re: Improvements to dynamic-codege project

[saminda abeyruwan]

Hi Jonathan,

Thank you for the response. Please see the comments below,

Jonathan Marsh wrote:
> Cool!  I'll try to help.  See below.
> 
> Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
>  
> 
>> -----Original Message-----
>> From: saminda abeyruwan [mailto:saminda at wso2.com]
>> Sent: Monday, August 20, 2007 12:35 AM
>> To: wsas-java-dev at wso2.org
>> Cc: mashup-dev at wso2.org; Jonathan Marsh
>> Subject: Improvements to dynamic-codege project
>>
>> Hi All,
>>
>> We've been in the process of writing a generic "try it" tool to
>> generate an AJAX app for any WSDL available in the net using xslts
>> available in dynamic-codegen project.
>>
>> Design:
>> -------
>> WSAS will have a tool called "try it", which will generate the required
>> .stub.js and .html pages based on the given WSDL. (Implementation is
>> available in latest nightly builds).
>>
>> Constrains:
>> ----------
>> When implementing this feature, following constrains have been found in
>> the generated ".stub.js" and ".html" pages.
>>
>> 1. Though the given WSDL (ex:
>> http://www.webservicex.net/stockquote.asmx?wsdl) has different endpoint
>> addresses, the default will be generate according to the html page
>> "self.location.href" [1]. If the default address set to the SOAP11 or
>> SOAP12 and if it's calculated from the given WSDL, IMHO, that would
>> have
>>   been the correct way.
> 
> The tryit page has a function called fixEndpoints() called during
> initialization that does the endpoint address tweaking (removing
> inappropriate endpoints, changing the domain, etc) to avoid failures due to
> cross-domain security restrictions.  I suspect just removing this function
> call will keep the endpoints intact.  Would adding a parameter to suppress
> calling this function be an acceptable solution?

+1. Adding a parameter to call fixEndpoints() function would be 
appropriate considering the cross-domain security restrictions.

> 
>> 2. As the generated AJAX app running on different host and the given
>> WSDL has endpoints related to another host, SOP will come into play.
>> [2]. Thus, the generated AJAX application should be given a way to turn
>> on the Universal browser privileges or should be given a global  param
>> in XSL to inject the choice at transformation time. [2].
> 
> I see that I'm not calling
> netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect") at
> the right point.  I can fix that too, but that isn't a complete solution is
> it?  (What's the point of a restriction against malicious scripts if the
> malicious script can turn off the restriction? And, this doesn't help for
> IE, where the user has to configure "trusted domains".)  At the least you
> might have to "program" the user with extra instructions in the page.
> 

Considering the nature of "try it" feature, IMHO we could live with the 
hazards that a malicious script could do as you mentioned. For IE, lets 
provide a placeholder in the documentation section that we could 
instruct the users to set the "trusted domains." A parameter would be 
suffix for this, thus, we could inject the instruction in the 
transformation time.


Thank you

Saminda

>> Shall I open a JIAR to the above matters in MASHUP project.
> 
> Sure, or in the COMMONS project - that's where existing issues are filed.
> Though I check this list more often than the commons-dev list.
> 
>> Your thoughts on the prior would be really helpful.
>>
>> Thank you
>>
>> Saminda
>>
>>
>> Reference:
>>
>> [1]. Attached - shot1.jpg
>> [2]. Attached - shot2.jpg
>> [3]. http://www.webservicex.net/stockquote.asmx?wsdl
> 
>