Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Start Python at client side from web app

28 views
Skip to first unread message

Thomas Guettler

unread,
Jan 21, 2009, 3:10:55 AM1/21/09
to
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

--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de

Lars Behrens

unread,
Jan 21, 2009, 3:41:44 AM1/21/09
to
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?

--
Cheerz Lars

Paul Rubin

unread,
Jan 21, 2009, 4:06:41 AM1/21/09
to
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?

7stud

unread,
Jan 21, 2009, 4:57:52 AM1/21/09
to
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?

James Stroud

unread,
Jan 21, 2009, 5:10:45 AM1/21/09
to
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.

James

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com

Diez B. Roggisch

unread,
Jan 21, 2009, 5:21:34 AM1/21/09
to
James Stroud wrote:

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.

Diez

Thomas Guettler

unread,
Jan 21, 2009, 6:17:16 AM1/21/09
to
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:

Diez B. Roggisch

unread,
Jan 21, 2009, 6:21:57 AM1/21/09
to
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.

Diez

James Stroud

unread,
Jan 21, 2009, 4:08:48 PM1/21/09
to
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.

Rob Williscroft

unread,
Jan 21, 2009, 5:59:18 PM1/21/09
to
Thomas Guettler wrote in news:6toehtF...@mid.individual.net in
comp.lang.python:

> 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?

Two options come to mind:

1) use a HTA as you client app,

http://msdn.microsoft.com/en-us/library/ms536496(VS.85).aspx

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.

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

Diez B. Roggisch

unread,
Jan 21, 2009, 6:05:10 PM1/21/09
to

> 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.

Diez

Rob Williscroft

unread,
Jan 21, 2009, 6:20:38 PM1/21/09
to
Diez B. Roggisch wrote in news:6tpo16F...@mid.uni-berlin.de in
comp.lang.python:

Are you thinking of frames?, or the way IE 7 complains about
runnning javavscript (though it bizzarly calls it an "running
an ActiveX control" )?.

Anyway it works fine.


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

Bryan Olson

unread,
Jan 21, 2009, 7:47:29 PM1/21/09
to
Thomas Guettler wrote:
> Sorry, I described my problem not well. Here is more information:

Actually you did pretty well.

[...]


> The main application is the intranet web application used with IE (ms windows client).

Your idea of a custom mime-type, with a browser extension, should work.
I don't know of any open-source implementation.

Do you plan to have just one public key for verifying the downloaded
Python scripts, hard-coded into the extension?


--
--Bryan

Paul Rubin

unread,
Jan 21, 2009, 9:17:15 PM1/21/09
to
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:

http://msdn.microsoft.com/en-us/library/ms536496(VS.85).aspx

Also, rather than concocting your own code signing system, maybe you
want to use standard Python .exe packaging, signed with Authenticode.

Thomas Guettler

unread,
Jan 22, 2009, 6:33:24 AM1/22/09
to
Bryan Olson schrieb:

Yes, that's what plan: one hard-coded public key is on the client.

Thomas

Thomas Guettler

unread,
Jan 22, 2009, 6:38:10 AM1/22/09
to
Diez B. Roggisch schrieb:

A page requested from "http://myintranetserver/" can redirect to "http://localhost:myport/myapp/?foo=..."

this would work.

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

Thomas Guettler

unread,
Jan 22, 2009, 7:13:55 AM1/22/09
to
Paul Rubin schrieb:

Authenticode looks like a Microsoft invention. Although I need this
for windows now, it should be portable.

Thomas

Diez B. Roggisch

unread,
Jan 22, 2009, 2:40:38 PM1/22/09
to
Rob Williscroft schrieb:

> Diez B. Roggisch wrote in news:6tpo16F...@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.

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.

Diez

Rob Williscroft

unread,
Jan 22, 2009, 4:37:44 PM1/22/09
to
Thomas Guettler wrote in news:6tr453F...@mid.individual.net in
comp.lang.python:

> Diez B. Roggisch schrieb:
>>
>>> 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.
>
> A page requested from "http://myintranetserver/" can redirect to
> "http://localhost:myport/myapp/?foo=..."
>
> this would work.
>
> But how should the web server at localhost be started? You need to
> write a Windows service.

Since there will be only one client a regular programme
should be fine.

> I guess that's not very easy, since I am not
> used to windows programming.

Then don't do any (windows programming), do Python:

http://docs.python.org/3.0/library/wsgiref.html#module-
wsgiref.simple_server

http://docs.python.org/3.0/library/cgi.html#functions

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

Rob Williscroft

unread,
Jan 22, 2009, 4:59:22 PM1/22/09
to
Diez B. Roggisch wrote in news:6ts0dnF...@mid.uni-berlin.de in
comp.lang.python:

> Rob Williscroft schrieb:
>> Diez B. Roggisch wrote in news:6tpo16F...@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/

Paul Rubin

unread,
Jan 22, 2009, 5:48:19 PM1/22/09
to
"Diez B. Roggisch" <de...@nospam.web.de> writes:
> 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.

Arlo Belshee

unread,
Jan 28, 2009, 2:37:25 AM1/28/09
to
> 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.

0 new messages