cross-domain

[ampo]

Hello.

Can anyone help with cross-domain problem?
I have HTML page from server1 that send xmlHTTPRequest to server2.

How can I do it?

Thanks.

 

[SAM]

Le 10/18/08 11:32 PM, ampo a écrit :

Hello.

Can anyone help with cross-domain problem?
I have HTML page from server1 that send xmlHTTPRequest to server2.

How can I do it?

You send your XHR to the server of your domain.
The PHP (or other language) on this server will call and get the infos
on the other server.

 

[Bart Van der Donck]

Can anyone help with cross-domain problem?
I have HTML page from server1 that send xmlHTTPRequest to server2.
How can I do it?

You might be interested in Ajax Cross Domain:

http://www.ajax-cross-domain.com/

 

[Thomas 'PointedEars' Lahn]

You might be interested in Ajax Cross Domain:

http://www.ajax-cross-domain.com/

CAVEAT: Each and every bit of information sent and retrieved using this
method goes over a third-party server!

While it is rather easy to set up server-side URL rewrite on one's own
server, even without any knowledge of server-side scripting.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Can anyone help with cross-domain problem?
I have HTML page from server1 that send xmlHTTPRequest to server2.

How can I do it?

First of all, this could be a digital rights issue. Make sure that you have
*written* authorization to use content of others in your Web site before you
use it.

Second, you can use either server-side URL rewrite, such as
<http://httpd.apache.org/docs/2.0/misc/rewriteguide.html> or a server-side
proxy script *on your server*.


PointedEars

 

[Bart Van der Donck]

CAVEAT: Each and every bit of information sent and retrieved using this
method goes over a third-party server!

The default installation works with a web page that calls /cgi-bin/
ACD.js on the same website (though the .js may also reside on another
domain). ACD.js then does the request to the remote server. For
example:
http://www.ajax-cross-domain.com/#Synopsis
http://www.ajax-cross-domain.com/runit/1.htm
Two domains involved: the caller (ajax-cross-domain.com) and the
remote site (google.com).

Maybe the text "or as managed service on ajax-cross-domain.com" had
created this confusion:
http://www.ajax-cross-domain.com/#Flowchart

The default installation is on the same website though:
http://www.ajax-cross-domain.com/#Installation

While it is rather easy to set up server-side URL rewrite on one's own
server, even without any knowledge of server-side scripting.

That would be a suitable alternative, yes.

 

[Thomas 'PointedEars' Lahn]

The default installation works with a web page that calls /cgi-bin/
ACD.js on the same website (though the .js may also reside on another
domain). ACD.js then does the request to the remote server. For
example:
http://www.ajax-cross-domain.com/#Synopsis
http://www.ajax-cross-domain.com/runit/1.htm
Two domains involved: the caller (ajax-cross-domain.com) and the
remote site (google.com).

Nevertheless, those who have a domain of their own usually don't need your
script (as they can put .htaccess and friends), and those who don't have a
domain usually can't run your script on their server (who can't/won't afford
a domain usually can't get CGI and friends because there are just not enough
ads that would pay for it).

So the latter group should be made aware that all their requests and
responses can be spied^Wlogged on, either by you (no offense meant, but a
statement of confidentiality is missing from your documentation), or a
man-in-the-middle because the connection is only partially encrypted (from
your server to the target host) at best.

There is also the inherent insecurity of passing sensitive data in URIs to
consider, since they end up in the local history and caches, proxy caches,
and default Web server logs. Not to mention the limitation of data to be
transmitted because browsers (and particularly that of the browser with
still the greatest market share, like it or not); BTW, that limit is at 2083
characters per URI in IE, not 2048.

Given these facts, I have to question the overall usefulness of your
script/service, even if your intentions may be good.


PointedEars

 

[Bart Van der Donck]

http://www.ajax-cross-domain.com/ [...]

Nevertheless, those who have a domain of their own usually don't need your
script (as they can put .htaccess and friends), and those who don't have a
domain usually can't run your script on their server (who can't/won't afford
a domain usually can't get CGI and friends because there are just not enough
ads that would pay for it).

Access to a CGI-enabled directory is needed, yes, but not the own
domain. The script runs from/to any location that supports CGI written
in Perl.

So the latter group should be made aware that all their requests and
responses can be spied^Wlogged on, either by you (no offense meant, but a
statement of confidentiality is missing from your documentation),

I cannot view/spy/log the requests. The webserver where the script
runs, can. None of the 4284 downloads of the past years runs on my
machine (except the demo) so I cannot view or log anything.

or a man-in-the-middle because the connection is only partially encrypted
(from your server to the target host) at best.

Ajax Cross Domain can run over HTTPS or HTTP. It doesn't make a
difference. Also a combination is possible:
- caller file over HTTP and ACD.js over HTTPS
- caller file over HTTPS and ACD.js over HTTP (in this case, the
browser might give a warning, because a HTTPS page requests a HTTP
javascript file, so I would not recommend this setup)

The requested remote file can use connections over http:, https:,
ftp:, gopher: and a few (theoretical) others. It uses Gisle
Aas' LWP module:
http://search.cpan.org/~gaas/libwww-perl/lib/LWP.pm#NETWORK_SUPPORT

There is also the inherent insecurity of passing sensitive data in URIs to
consider, since they end up in the local history and caches, proxy caches,
and default Web server logs.  

Very true. The issue is described at the second paragraph of chapter
'Security':
http://www.ajax-cross-domain.com/#Security

But I think the risk must not be exaggerated; it's indeed inherent for
this kind of requests as you write. It's not different with Apache
rewrite rules or proxies; they can all be eavesdropped as well.

IMHO the first paragraph about security ("Calling ACD.js is only
allowed with certain query-strings") is more important.

Not to mention the limitation of data to be transmitted because browsers
(and particularly that of the browser with still the greatest market
share, like it or not); BTW, that limit is at 2083 characters per URI in
IE, not 2048.

Yes, 2048 is the path size, not the full URL. It has been corrected.

Given these facts, I have to question the overall usefulness of your
script/service, even if your intentions may be good.

Google Analytics shows between 50-100 unique visitors per day, with
10-15 daily downloads of the script. I think that remote requests from
js reflect a real need from programmers.

Thanks for the feedback.