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

[Jonathan Marsh]

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
> 
> -----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-----
> 
> _______________________________________________
> Mashup-dev mailing list
> Mashup-dev at wso2.org
> http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev