Hoping to clarify:

Having a page built up of parts that come from different domains adds
value and power.  Having a page built up of parts from different domains
adds complexity, lack of control and security hazards.

There are browser rules that determine what kind of things can be done
between different domains in an attempt to balance these two factors.

Things the browser won't let you do between domains:
 - use JS to get any info about other pages in the browser served from
   the different domains (including those in frames)
 - use JS to trigger any kind of activity in the window context of
   a page served by another server
 - XmlHttpRequest from a page in one server to a URL in another
 - share cookies (depending on user settings)

Things the browser will let you do between domains
 - embed on a page an image from a different server
 - embed in a page a JS from another server
 - embed in a page a CSS from another server
 - anchor link to a page on a different server
 - share cookies (depending on user settings)

As you might guess, existing third part mashups and APIs use some
combination of things from the second list.  Most people would consider
them Ajax even though they rely on including Javascript files, image
requests, etc., not on using the XmlHttpRequest.

And for anyone who read the list and is now thinking... "wait, what? I
can include arbitrary executable code on my page with no restrictions
(JS file) but I can't do an http request for a piece of content that I
then process with any level of care I deem necessary (XmlHttpRequest)?"
Yes it is crazy and I'm pretty sure the reasons are historical.

All of this leaves the fundamental problem more or less unsolved.  What
do you do about functionality that might add power but might erode
security?

Opera has done some work on an API for passing info from one domain to
the other.  It involves defining a way for JS code to shove objects and
event handlers into a formally shared space.  By exposing only the API
you want to expose (and with the ability to limit who you expose it to)
it greatly reduces the security risks.

To some extent this model is already available using the double iframe
hack, which relies on the fact that if a page creates an iframe whose
source goes to another server, and that inner page creates an iframe
whose source is back in the outermost server's domain, the innermost and
outermost iframes can share data.  Both pages can manipulate the URL of
the innermost iframe and share information that way.

------>Nathan


.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:
||:.

Nathan Young
Cisco.com->Interface Development
A: ncy1717
E: [EMAIL PROTECTED]  

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Alex Cook
> Sent: Friday, March 16, 2007 10:09 AM
> To: [EMAIL PROTECTED]; jQuery Discussion.
> Subject: Re: [jQuery] php - web service (ajax/jscript)
> 
> I was about to write out this detailed explanation of how you all are
> making this much harder on yourselves then necessary but Bruce beat me
> too it :)
> 
> Any script included at runtime = safe
> 
> Anything attempted to be loaded AFTER runtime = unsafe
> 
> -ALEX
> 
> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On
> Behalf Of bruce
> Sent: Friday, March 16, 2007 10:02 AM
> To: 'jQuery Discussion.'; [EMAIL PROTECTED]
> Subject: Re: [jQuery] php - web service (ajax/jscript)
> 
> jake...
> 
> now i'm laughing!!!!
> 
> here's how i understand it with a very limited amont of time 
> to research
> this.
> 
> the basic ajax/jscript allows for asynch communications between the
> server
> that serves the jscript file. cross-domain issues arise when 
> you'd want
> the
> ajax/jscript to not only communicate with the 'hosted'/parent server,
> but
> also to another server's api as well, (with this server being 
> in another
> domain).
> 
> this is why in the html/php, you'll have the following kind of code:
> <script>
> <src='http://www.google.com/api/maps/foo?....'>
> </script>
> 
> rest of the html page..
> 
> this effectively means that the '..maps/foo' is being served 
> up from the
> google server, but it's running on your client app.
> 
> this is also why you can have mashup functions, where your 
> app is using
> the
> apis of multiple systems/servers... you're using separate apis, which
> are
> being served from separate servers.
> 
> so. now that i've clarified it a little, how about you telling me how
> good
> you are with jscript! i have a jscript issue that i'm trying 
> to solve!!
> 
> thanks
> 
> -bruce
> 
> 
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Jake McGraw
> Sent: Friday, March 16, 2007 9:48 AM
> To: jQuery Discussion.
> Subject: Re: [jQuery] php - web service (ajax/jscript)
> 
> 
> Actually, thats a damn good point, I use Google Maps on some of my
> websites,
> and yet I gave that answer to you, perhaps they're using 
> Iframes? Anyone
> have an answer for this, now you got me interested!
> 
> - jake
> 
> 
> On 3/16/07, bruce <[EMAIL PROTECTED]> wrote:
> jake...
> 
> if what you state is true. how does 
> google/yahoo/flickr/etc... manage to
> allow 3rd party websites to access their hosted apis, which 
> are resident
> on
> the hosted server of google/yahoo/etc....
> 
> 
> -bruce
> 
> -----Original Message-----
> From: Jake McGraw [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 16, 2007 9:17 AM
> To: [EMAIL PROTECTED]
> 
> Subject: Re: [jQuery] php - web service (ajax/jscript)
> 
> 
> Bruce,
> 
> I believe, regardless of the website serving the Javascript file, AJAX
> will
> only interface with the server that actually served the 
> entire document.
> 
> What I suggest you do is provide clients with a PHP Script / HTML
> Template
> (Smarty is very good for this) with some AJAX Javascript.
> 
> The PHP Script can contact your web service (you can use the PEAR
> SOAP/WSDL
> extensions or go for the full blown Tomcat/Apache config), serve
> whatever
> information you like back to the PHP Script and then back to the
> browser:
> 
> Request
> Web Browser/AJAX -- (XML or JSON) --> Client Server/PHP/SOAP -- (XML)
> -->
> Your Server/(PHP or Tomcat)
> 
> Return
> Your Server/(PHP or Tomcat) -- (XML) --> SOAP/PHP/Client 
> Server -- (XML
> or
> JSON) --> AJAX/Web Browser
> 
> So basically, your clients would need a web server that 
> handles PHP and
> can
> make SOAP Requests, you would author the PHP/HTML template and release
> that
> as an "api". This is probably the best way to go about things 
> because it
> allows non-web browsers user access to your Web Service and it keeps
> with
> the whole concept of what web services should truly be.
> 
> - jake
> 
> 
> On 3/16/07, bruce <[EMAIL PROTECTED]> wrote:
> > Hi Jake.
> >
> > Thanks for the reply. I'll try to clarify. (Keep in mind, I'm not an
> > experienced web developer!)
> >
> > As I understand Ajax, it's used to allow asynch interaction between
> client,
> > and hosted site that the client js file is fetched from. In other
> words,
> if
> > the client html/php has something to the effect:
> >
> >   <html>
> >   <script>
> >   <src = 'http://www.homeserver.com/test.js' >
> >   </html>
> >
> > Even though the client html/php might be on the 'foo' site
> > (www.foo.com/test.html), the test.js functionality is being served
> from
> the
> > 'homeserver.com' domain, and can therefore 
> interface/communicate with
> the
> > 'homeserver'. This is what I want to accomplish, as it allows me to
> create
> > test servers/apps, and they can each communicate via the 
> test api/web
> > service (on homeserver.com) with the homeserver web service.
> >
> > so i'm trying to get my hands around how to create/implement a test
> app to
> > demonstrate this. A rough overview is:
> >
> >  Assume:
> >     Master Server                        3rd Party Server (separate
> domain)
> >       App1                                   Test App
> >       API File                               (aa.js) (from Master
> Server)
> >       JScript (aa.js) ------>>-----------------^
> >
> >  The aa.js file allows the 3rd party client site to be able to
> interface
> > with
> >  the Master Server API via the API/services defined in the API File.
> I'm
> >  envisioning the following actions for the user
> >
> >    3rd Party Site                       Master Server
> >       -User Enters Name >>>>>>>>>>>>>>    api checks/verifies name
> >       -gets response
> >         Master Server    <<<<<<<<<<<<<<   returns response
> >       -user answers
> >        question based
> >        on response,
> >        sends response
> >        to master server
> >        via api          >>>>>>>>>>>>>>   api checks user input
> >       -gets response
> >         Master Server    <<<<<<<<<<<<<<   returns response
> >       -jscript then
> >        gives reply/response
> >        to the 3rd Party site,
> >        allowing the site/app
> >        to continue processing
> >
> >  In this case, the jscript/ajax app is really only 
> communicating with
> the
> >  Master Server, which if I understand it correctly would be in the
> same
> >  domain as the ajax/jscript code. In other words, if the 
> master server
> >  supplies the jscript file(s) for the jscript that's to be 
> run on the
> 3rd
> >  party server, then any communication that's initiated from the
> jscript is
> >  going back to the master server. There shouldn't be a cross domain
> issue?
> >  Yes/No???
> >
> > So I'm trying to find docs/help/information (someone to 
> talk to) so I
> can
> > create a test app that accomplishes this kind of functionality.
> >
> > Thanks
> >
> > -Bruce
> >
> >
> > -----Original Message-----
> > From: Jake McGraw [mailto:[EMAIL PROTECTED]
> > Sent: Friday, March 16, 2007 7:07 AM
> > To: [EMAIL PROTECTED]; jQuery Discussion.
> > Subject: Re: [jQuery] php - web service (ajax/jscript)
> >
> >
> > Bruce:
> >
> > I'm not sure I fully understand what you are trying to 
> accomplish, but
> > AJAX is not a replacement for SOAP/WSDL Web Services as it 
> is strictly
> > limited to communication within its own domain, which flies in the
> > face of Web Services philosophy.
> >
> > Could you provide a more concise example of what you would 
> like to do?
> >
> > - jake
> >
> > On 3/15/07, bruce <[EMAIL PROTECTED]> wrote:
> > > Hi
> > >
> > > I'm trying to find information with regards to how to
> create/implement a
> > > test web services app. I'm trying to find pointers to anyone who's
> > actually
> > > created this kind of functionality, or pointers to web 
> sites where I
> can
> > > find the information I'm looking for.
> > >
> > > For my test, App1 has the web service, and provides the 
> jscript/ajax
> code
> > to
> > > the 3rd Party, for use on the Test App. I'm trying to 
> find php code
> for
> > the
> > > apps on the web servers as well as test php code for the 
> api on the
> Master
> > > Server. I'm also trying to get/find a test situation that provides
> test
> > > client code (jscript/ajax) to be implemented on the test 
> server/app.
> > >
> > > Assume:
> > >    Master Server                        3rd Party Server (separate
> domain)
> > >      App1                                   Test App
> > >      API File                               (aa.js) (from Master
> Server)
> > >      JScript (aa.js) ------>>-----------------^
> > >
> > > The aa.js file allows the 3rd party client site to be able to
> interface
> > with
> > > the Master Server API via the API/services defined in the 
> API File.
> I'm
> > > envisioning the following actions for the user
> > >
> > >   3rd Party Site                       Master Server
> > >      -User Enters Name >>>>>>>>>>>>>>    api checks/verifies name
> > >      -gets response
> > >        Master Server    <<<<<<<<<<<<<<   returns response
> > >      -user answers
> > >       question based
> > >       on response,
> > >       sends response
> > >       to master server
> > >       via api          >>>>>>>>>>>>>>   api checks user input
> > >      -gets response
> > >        Master Server    <<<<<<<<<<<<<<   returns response
> > >      -jscript then
> > >       gives reply/response
> > >       to the 3rd Party site,
> > >       allowing the site/app
> > >       to continue processing
> > >
> > > In this case, the jscript/ajax app is really only 
> communicating with
> the
> > > Master Server, which if I understand it correctly would be in the
> same
> > > domain as the ajax/jscript code. In other words, if the master
> server
> > > supplies the jscript file(s) for the jscript that's to be 
> run on the
> 3rd
> > > party server, then any communication that's initiated from the
> jscript
> is
> > > going back to the master server. There shouldn't be a cross domain
> issue?
> > > Yes/No???
> > >
> > > So, anyone who's actually implemented a real live web service,
> that's
> > > willing to talk to me would be helpful, or if you can point me to
> sample
> > > docs/code...
> > >
> > > Thanks
> > >
> > > -bruce
> > >
> > >
> > >
> > > _______________________________________________
> > > jQuery mailing list
> > > [email protected]
> > > http://jquery.com/discuss/
> > >
> >
> >
> 
> 
> _______________________________________________
> jQuery mailing list
> [email protected]
> http://jquery.com/discuss/
> 
> _______________________________________________
> jQuery mailing list
> [email protected]
> http://jquery.com/discuss/
> 

_______________________________________________
jQuery mailing list
[email protected]
http://jquery.com/discuss/

Reply via email to