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

Wed Jun 6 10:24:31 PDT 2007

I added a way to view, and edit, the addresses in the tryit a day or more
ago.

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: Wednesday, June 06, 2007 4:45 AM
> To: mashup-dev at wso2.org
> Subject: Re: [mashup-dev] WSAS Prominent Network Interface Re-direction
> inherited in the Mashup Server
> 
> -----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-----
> 
> _______________________________________________
> Mashup-dev mailing list
> Mashup-dev at wso2.org
> http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev