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

Wed Jun 6 04:45:08 PDT 2007

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

Hi All,

If the decision is to list names of endpoints, thus, user can select one
 from the list, then rather showing only the names, if we can show the
associated protocol (or endpoint address) with that it would be easier
to the user.

ex:

soap11port0 [http]

or

soap11port0 [http://foo.org/bar]

Thank you

Saminda

Jonathan Marsh wrote:
> So the changes to the tryit are:
> 1) replace the domain:port of the endpoint with the domain:port of the
> service.
> 2) provide a facility for the user to change the endpoint address (I've
> already considered this as useful for allowing tcpmon and built some
> accessors into the stub, but haven't provided a UI for it.)
> 
> I think this raises another issue related to MASHUP-61.
> 
> The endpoint selection facility in the tryit today allows you to choose
> different endpoints from both http://...:9762 and from https://...:9443.  If
> I just replace the domain name the http/https will no longer match up with
> the port number.  Also, the XMLHTTP browser security restrictions will
> prevent the use of secure endpoints from the non-secure tryit and vice
> versa.
> 
> A possible solution is to have the tryit filter out the https endpoints from
> http and the http ones from https, and then provide a link to the
> secure/unsecure version of the tryit to make access to all endpoints
> available. 
> 
> Another solution would be to continue to show all endpoints, but when a
> cross-domain one is selected, present the user with a dialog asking if
> they'd like to redirect to the appropriate tryit so that the request
> endpoint address can be accessed.
> 
> Comments?
> 
> 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 Thilina Gunarathne
>> Sent: Monday, June 04, 2007 8:19 AM
>> To: mashup-dev at wso2.org
>> Subject: Re: [mashup-dev] WSAS Prominent Network Interface Re-direction
>> inherited in the Mashup Server
>>
> 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
> 
>>
_______________________________________________
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.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGZp5EYmklbLuW6wYRAnHnAKCYneVry8xNtCWkzXswo7GinEVMwwCeKASo
32ZmEszG2M1IHd4yoJ017sE=
=9OBe
-----END PGP SIGNATURE-----