I want to start Python at the client side from a web application. The app is an intranet application, and all client PCs are under our control (we can install software on them).
But I don't want to update the installation too often. Here is my idea:
We create a custom mime-type and register it on the client PC. The web application can send signed python code to the client PC. If the signature is correct, the code will be executed at the client. The signature prevents others from executing code.
Has someone seen or done something like this before?
I can code this myself, but prefer to use some open source project, if it exists.
Thomas Guettler wrote: > But I don't want to update the installation too often. Here is my idea:
> We create a custom mime-type and register it on the client PC. The web > application can send signed python code to the client PC. If the signature > is correct, the code will be executed at the client. The signature > prevents others from executing code.
My first thought was: Wouldn't it be much easier to start the script via ssh?
Thomas Guettler <h...@tbz-pariv.de> writes: > I want to start Python at the client side from a web > application. The app is an intranet application, and all client PCs > are under our control (we can install software on them).
Is it supposed to be OS independent? If not, is it for a specific OS? Which one?
On Jan 21, 1:10 am, Thomas Guettler <h...@tbz-pariv.de> wrote:
> Hi,
> I want to start Python at the client side from a web application. The > app is an intranet application, and all client PCs are under our control (we > can install software on them).
> But I don't want to update the installation too often. Here is my idea:
> We create a custom mime-type and register it on the client PC. The web application > can send signed python code to the client PC. If the signature is correct, > the code will be executed at the client.
How does a web application on the client execute python code?
> I want to start Python at the client side from a web application. The > app is an intranet application, and all client PCs are under our control (we > can install software on them).
> But I don't want to update the installation too often. Here is my idea:
> We create a custom mime-type and register it on the client PC. The web application > can send signed python code to the client PC. If the signature is correct, > the code will be executed at the client. The signature prevents others from executing > code.
> Has someone seen or done something like this before?
> I can code this myself, but prefer to use some open source project, if it exists.
> Thanks in advance, > Thomas Güttler
You are better off using a cron job (or similar) on the client side, getting the client to hit the web server for the code at regular intervals, and if code is ready, execute. If code isn't ready, wait for the next interval. Use https for security and have a shared secret message to identify legitimate clients.
If you try to push code the other way, you will need a perpetual socket open on the client side, making the client the server.
James
-- James Stroud UCLA-DOE Institute for Genomics and Proteomics Box 951570 Los Angeles, CA 90095
James Stroud wrote: > Thomas Guettler wrote: >> Hi,
>> I want to start Python at the client side from a web application. The >> app is an intranet application, and all client PCs are under our control >> (we can install software on them).
>> But I don't want to update the installation too often. Here is my idea:
>> We create a custom mime-type and register it on the client PC. The web >> application can send signed python code to the client PC. If the >> signature is correct, the code will be executed at the client. The >> signature prevents others from executing code.
>> Has someone seen or done something like this before?
>> I can code this myself, but prefer to use some open source project, if it >> exists.
>> Thanks in advance, >> Thomas Güttler
> You are better off using a cron job (or similar) on the client side, > getting the client to hit the web server for the code at regular > intervals, and if code is ready, execute. If code isn't ready, wait for > the next interval. Use https for security and have a shared secret > message to identify legitimate clients.
> If you try to push code the other way, you will need a perpetual socket > open on the client side, making the client the server.
If the OP finds a method to trigger the execution of his program, the question of who's client and who not is moot. If he wants, he can make the software query a server via HTTP (he's got that up & reachable from the PC anyway) for it's new code. All he needs is some session-key being passed on invocation.
Sorry, I described my problem not well. Here is more information:
The main application is the intranet web application used with IE (ms windows client). But some action needs to be done on the client since you can't do it with html or javascript.
1. The user pushes a button in the web app. 2. Webserver sends signed python code to the client with own mime type 3. IE sends code to the python application. 4. Signature gets checked, Python code on the client gets executed. 5. Maybe send some data to the server with http.
> I want to start Python at the client side from a web application. The > app is an intranet application, and all client PCs are under our control (we > can install software on them).
> But I don't want to update the installation too often. Here is my idea:
> We create a custom mime-type and register it on the client PC. The web application > can send signed python code to the client PC. If the signature is correct, > the code will be executed at the client. The signature prevents others from executing > code.
> Has someone seen or done something like this before?
> I can code this myself, but prefer to use some open source project, if it exists.
Thomas Guettler wrote: > Sorry, I described my problem not well. Here is more information:
> The main application is the intranet web application used with IE (ms > windows client). But some action needs to be done on the client since you > can't do it with html or javascript.
> 1. The user pushes a button in the web app. > 2. Webserver sends signed python code to the client with own mime type > 3. IE sends code to the python application. > 4. Signature gets checked, Python code on the client gets executed. > 5. Maybe send some data to the server with http.
As I already told you on the german python NG (why do you post on *two* lists?), I'd rather go for a custom network protocol.
This is supported by the various OSses, and browsers just hook into it. Then, when the user presses a "myprotocol://some/parameters"-link (or get's redirected there through JS), the registered application will be fired up to handle the url.
You then simply use the passed parameters to make a call to your webserver to fetch the new code.
Thomas Guettler wrote: > Sorry, I described my problem not well. Here is more information:
> The main application is the intranet web application used with IE (ms windows client). > But some action needs to be done on the client since you can't do it with html or javascript.
> 1. The user pushes a button in the web app. > 2. Webserver sends signed python code to the client with own mime type > 3. IE sends code to the python application. > 4. Signature gets checked, Python code on the client gets executed. > 5. Maybe send some data to the server with http.
You need to write an IE plugin for this, otherwise you can't get out of the browser sandbox to execute anything on the client side.
In fact, if you just make your IE "application" a plugin, you can take advantage of updating facilities that IE should have for plugins. If IE doesn't have updating facilities, then just write a firefox plugin, which does have these facilities.
> Sorry, I described my problem not well. Here is more information:
> The main application is the intranet web application used with IE (ms > windows client). But some action needs to be done on the client since > you can't do it with html or javascript.
> 1. The user pushes a button in the web app. > 2. Webserver sends signed python code to the client with own mime type > 3. IE sends code to the python application. > 4. Signature gets checked, Python code on the client gets executed. > 5. Maybe send some data to the server with http.
> Thomas
> Server runs Linux with Django and Postgres.
> Thomas Guettler schrieb: >> Hi,
>> I want to start Python at the client side from a web application. The >> app is an intranet application, and all client PCs are under our >> control (we can install software on them).
>> But I don't want to update the installation too often. Here is my >> idea:
>> We create a custom mime-type and register it on the client PC. The >> web application can send signed python code to the client PC. If the >> signature is correct, the code will be executed at the client. The >> signature prevents others from executing code.
>> Has someone seen or done something like this before?
The main drawback is it isn't a full browser so you loose things like back buttons, though some shortcuts F5 (refresh/reload) do work.
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.
> 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.
>> 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" )?.
Thomas Guettler <h...@tbz-pariv.de> writes: > 1. The user pushes a button in the web app. > 2. Webserver sends signed python code to the client with own mime type > 3. IE sends code to the python application. > 4. Signature gets checked, Python code on the client gets executed. > 5. Maybe send some data to the server with http.
I think someone else already suggested using an hta. Does that not do what you want? More info is at:
>> 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.
But how should the web server at localhost be started? You need to write a Windows service. I guess that's not very easy, since I am not used to windows programming.
> Thomas Guettler <h...@tbz-pariv.de> writes: >> 1. The user pushes a button in the web app. >> 2. Webserver sends signed python code to the client with own mime type >> 3. IE sends code to the python application. >> 4. Signature gets checked, Python code on the client gets executed. >> 5. Maybe send some data to the server with http.
> I think someone else already suggested using an hta. Does that not > do what you want? More info is at:
>>> 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.
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. """
>>> 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.
>>>> 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.
> 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. """
> Before posting, I tried a jQuery-ajax-call inside Firebug from some > random site to google. It bailed out with a security execption.
You should be able to get around the security policy with XUL in Firefox, or with an ActiveX control in MSIE. In the Netscape Navigator era there was a security policy Java object so you could turn the security stuff on and off if the user gave permission from a pop-up dialog. I've been away from that scene for a while so I don't know if Firefox has anything like it.
> We create a custom mime-type and register it on the client PC. The web application > can send signed python code to the client PC. If the signature is correct, > the code will be executed at the client. The signature prevents others from executing > code.
This will let you start a program from within the browser. It will not let you run arbitrary Python inside the browser but it doesn't sound like that's your goal.
If you goal is "user can go to site, click button, hit OK on confirmation box, and launch arbitrary Python code", then the mime type solution is probably the best bet. Just make your own custom extension which will launch the python interpreter on your file. Give it a mime type, and serve regular .py files with that extension and mime type. IE will start the interpreter in a new process and pass your file along.
To verify the file's signature, you could simply create a custom interpreter by making a console app that takes a file, checks a sig, then runs the file against an embedded interpreter. Embedding the interpreter is simple enough.
> I can code this myself, but prefer to use some open source project, if it exists.
I don't know of any such.
Heck, if you don't care about checking the signature on the file before running, your "project" could consist of a .reg file that sets up your extension/file type/mime type. Do an MSI if you want to get really fancy, but all you really need to do is add a couple entries to the registry.
Of course, everything's a lot harder if you want to run within the browser. Having the browser ask the user for permission then launch a new process is easy. Building an integrated experience that hosts Python inside the browser sandbox is a lot harder - and probably not necessary.
