Diez B. Roggisch wrote in news:6ts0dnfc9s0...@mid.uni-berlin.de in comp.lang.python:
> Rob Williscroft schrieb: >> Diez B. Roggisch wrote in news:6tpo16fbacf...@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/
-- http://mail.python.org/mailman/listinfo/python-list
