[mashup-dev] WSAS Prominent Network Interface Re-direction inherited in the Mashup Server

[Thilina Gunarathne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,
It's good that Tyrell brought up this issue. We had long and hard off-line debates about this redirection policy with the WSAS team :)..

Earlier WSAS was using the host name(always the prominent IP), port & service context sent by the server side to perform the service calls. Now we decided to use the host address obtained from the browser to call the backend services.
So when the user types "localhost" in the browser, the js file would come from the "localhost". Then all the service calls will be made to the "http://localhost:port//services/.....".

We might need to change the tryit() to use the same browser host name, instead of the hostname given in the WSDL to perform the calls to the services. Also I feel it would be nice to provide an option for the user to type in the host name..

Thanks,
Thilina
> It appears that the same origin policy is unable to distinguish different
> names for the same origin (localhost, 127.0.0.1, the current IP).  By
> definition these aren't different origins so while the policy might be good
> from a security perspective, this is a bogus application of it.  The issue
> arises when some, but not all, of the relevant URIs are redirected, fooling
> the browser into thinking there are multiple origins.  I don't think we can
> get the browser fixed (of course you could all switch to Windows and IE, but
> that seems rather drastic ;-).  So I think we should look more closely at
> our redirection strategy.
> 
> We need support for the following scenarios:
> 
> 1) Online try-it.  User goes to
> http://localhost:9762/services/myservice?tryit.  The try it page imports
> ?stub, which in turn contains absolute endpoint addresses such as
> http://localhost:9762/services/myservice.  Regardless of any redirection
> that occurs, the tryit should work every time regardless of changes in the
> IP address (assuming the Mashup Server can dynamically change its IP along
> with the rest of the computer).
> 
> 2) Offline stubs.  User goes to
> http://localhost:9762/services/myservice?stub and saves the result for
> offline use, for instance in a desktop gadget (where there are no same
> origin policies).  The endpoint addresses are now frozen, yet need to work
> regardless of IP changes (i.e. they have to use localhost or 127.0.0.1).
> 
> 3) Mashups.  A service calls another service running on the same Mashup
> Server.  The endpoint addresses are hardcoded, yet must continue to work
> regardless of IP changes.
> 
> I think these scenarios point to being able to use localhost throughout the
> product - in accessing the management UI as well as the endpoint addresses.
> The current redirection strategy seems to break that, and it's not clear why
> it's necessary - it's introducing bogus differences in origin when it
> doesn't seem necessary.  If I were able to access the console through
> localhost, and the artifacts it handed back to me were from that same
> domain, I could store them offline and use them effectively regardless of IP
> changes.
> 
> Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
>  
>> -----Original Message-----
>> From: mashup-dev-bounces at wso2.org [mailto:mashup-dev-bounces at wso2.org]
>> On Behalf Of saminda abeyruwan
>> Sent: Friday, June 01, 2007 8:54 AM
>> To: mashup-dev at wso2.org
>> Subject: Re: [mashup-dev] WSAS Prominent Network Interface Re-direction
>> inherited in the Mashup Server
>>
> Hi,
> 
> In WSAS, we are enforcing this due to "Same Origin Policy:
> Protecting Browser State from Web Privacy Attacks". This has been
> enforced in Firefox 1.5 onwards.
> 
> For more info please refer to
> http://kb.mozillazine.org/Security_Policies
> 
> Thus, simply, if your machine has assigned an IP, Firefox doesn't allow
> you to fetch data from XMLHttpRequest, if loopback address is used.
> 
> The work around to these problems has been a simple redirection to the
> prominent address.
> 
> We didn't experience SOP problems in IE6 and IE7. (I'm a Linux guy :) )
> .
> 
> Thank you
> 
> Saminda
> 
> 
> Tyrell Perera wrote:
>>>> Hi all,
>>>>
>>>> I have noticed that since the Mashup Server is based on WSAS, it
>>>> redirects calls to the loopback address, to the prominent interface
> IP.
>>>> In other words, a user can not use 127.0.0.1 or localhost to connect
> to
>>>> the Mashup server.
>>>>
>>>> Since we are planning on allowing the users to install the server
>>>> locally in their individual machines, is this a vice approach?
>>>>
>>>> Consider a scenario where a user logs to a corporate network using
> DHCP.
>>>> This means his machine will have a dynamically allocated IP while on
> the
>>>> network and 'no IP' while disconnected. If this user tries to work on
>>>> the Mashup server while he is disconnected (i.e.; at home), he might
> not
>>>> be able to do so.
>>>>
>>>> I'm sure there is a valid reason behind the usage of this approach in
>>>> WSAS. But is it absolutely necessary on the Mashup server?
>>>>
>>>> Thanks,
>>>>
>>>> Tyrell
>>>>
>>>>
>>
_______________________________________________
Mashup-dev mailing list
Mashup-dev at wso2.org
http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev

> _______________________________________________
> Mashup-dev mailing list
> Mashup-dev at wso2.org
> http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFGZC1cTt0cKycFPQgRAhnRAKCZ1sZnRQvhJo4nvrzYSLk1FRzcjgCcDdmg
DbsxTSAHaBbK6I+lD7dVkpg=
=3uvN
-----END PGP SIGNATURE-----