Start Python at client side from web app

Thu Jan 22 16:59:22 EST 2009

Diez B. Roggisch wrote in news:6ts0dnFc9s0qU1 at mid.uni-berlin.de in
comp.lang.python: 

> Rob Williscroft schrieb:
>> Diez B. Roggisch wrote in news:6tpo16FbacfjU1 at mid.uni-berlin.de in
>> comp.lang.python: 
>> 
>>>> 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:

<body onload="document.forms[0].submit();">
<form action="http://localhost:8000/...">
<input ...>
</form>
</body> 

I.e. 1 line of JS that is manipulating the document of the page it
belongs to.

> 
> And I found this:
> 
> """
> 
> The Same-Origin Policy
> The primary JavaScript security policy is the same-origin policy. The 
> 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
> over" or manipulating documents from another. Without it, JavaScript
> 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. """
> 
> http://www.windowsitlibrary.com/Content/1160/22/1.html
> 
> 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
another option.

Rob.
-- 
http://www.victim-prime.dsl.pipex.com/