Start Python at client side from web app
rtw at freenet.co.uk
Thu Jan 22 22:59:22 CET 2009
Diez B. Roggisch wrote in news:6ts0dnFc9s0qU1 at mid.uni-berlin.de in
> Rob Williscroft schrieb:
>> Diez B. Roggisch wrote in news:6tpo16FbacfjU1 at mid.uni-berlin.de in
>>>> 2) create a localhost web server, for the client side manipulation.
>>>> Then have your remote webserver render a form that posts via
>>>> javavscript to the localhost webserver. The localhost server would
>>>> post back in the same way.
>>> AFAIK the JS security model prevents that.
>> Are you thinking of frames?, or the way IE 7 complains about
>> runnning javavscript (though it bizzarly calls it an "running
>> an ActiveX control" )?.
> Before posting, I tried a jQuery-ajax-call inside Firebug from some
> random site to google. It bailed out with a security execption.
Yes the XMLHttpRequest object only allows you to make requests
to the same domain as the page came from.
Here is a concrete example of what I suggested:
I.e. 1 line of JS that is manipulating the document of the page it
> And I found this:
> The Same-Origin Policy
> same-origin policy prevents scripts loaded from one Web site from
> getting or setting properties of a document loaded from a different
> site. This policy prevents hostile code from one site from "taking
> from a hostile site could do any number of undesirable things such as
> snoop keypresses while youâre logging in to a site in a different
> window, wait for you to go to your online banking site and insert
> spurious transactions, steal login cookies from other domains, and so
> on. """
> Now there might be ways around this - but these sure are hacky, and
> not exactly the thing to look after.
That is scripting across frames (or windows), where the frames
have a different origin (from different domain).
As an aside if the OP's app' can live with sending at most about
1KB of ascii back and forth then using a HTTP redirect header is
More information about the Python-list