Re: remote read eval print loop

Discussion in 'Python' started by Chris Angelico, Aug 16, 2012.

  1. On Fri, Aug 17, 2012 at 6:54 AM, Eric Frederich
    <> wrote:
    > Hello,
    >
    > I have a bunch of Python bindings for a 3rd party software running on the
    > server side.
    > I can add client side extensions that communicate over some http / xml type
    > requests.
    > So I can define functions that take a string and return a string.
    > I would like to get a simple read eval print loop working.


    Let's stop *right there*. You're looking for something that will run
    on your server, take strings of text from a remote computer, and eval
    them.

    Please, please, please, on behalf of every systems administrator in
    the world I beg you, please do not do this.

    Instead, define your own high-level protocol and have your server
    respond to that. One excellent way to keep things tidy is to use a
    'command, parameters, newline' model: each line of text is one
    instruction, consisting of a command word, then optionally parameters
    after a space, then a newline. It's easy to debug, easy to read in
    your code, and makes sense to anyone who's used a command-line
    interface.

    Six months from now, when your server still hasn't been compromised,
    you'll appreciate the extra design effort :)

    Chris Angelico
     
    Chris Angelico, Aug 16, 2012
    #1
    1. Advertising

  2. On Fri, 17 Aug 2012 08:43:50 +1000, Chris Angelico wrote:

    > On Fri, Aug 17, 2012 at 6:54 AM, Eric Frederich
    > <> wrote:
    >> Hello,
    >>
    >> I have a bunch of Python bindings for a 3rd party software running on
    >> the server side.
    >> I can add client side extensions that communicate over some http / xml
    >> type requests.
    >> So I can define functions that take a string and return a string. I
    >> would like to get a simple read eval print loop working.

    >
    > Let's stop *right there*. You're looking for something that will run on
    > your server, take strings of text from a remote computer, and eval them.
    >
    > Please, please, please, on behalf of every systems administrator in the
    > world I beg you, please do not do this.
    >
    > Instead, define your own high-level protocol


    Stop right there!

    There is already awesome protocols for running Python code remotely over
    a network. Please do not re-invent the wheel without good reason.

    See pyro, twisted, rpyc, rpclib, jpc, and probably many others.




    --
    Steven
     
    Steven D'Aprano, Aug 17, 2012
    #2
    1. Advertising

  3. On Fri, Aug 17, 2012 at 12:27 PM, Steven D'Aprano
    <> wrote:
    > There is already awesome protocols for running Python code remotely over
    > a network. Please do not re-invent the wheel without good reason.
    >
    > See pyro, twisted, rpyc, rpclib, jpc, and probably many others.


    But they're all tools for building protocols. I like to make
    line-based protocols that don't need middle-layers, you might like to
    use RPC, doesn't matter; either way, neither of us is sending
    untrusted code across the internet and executing it.

    By all means, use pyro instead of plain sockets to build your
    protocol; you still don't need a read/eval/print loop to run across a
    network.

    Personally, I'm of the opinion that simple text-based protocols are
    usually sufficient, and much easier to debug - heavier things like RPC
    tend to be overkill. But as Alister pointed out, my main point was not
    about the details of how you design your protocol.

    ChrisA
     
    Chris Angelico, Aug 17, 2012
    #3
  4. Chris Angelico

    rusi Guest

    On Aug 17, 12:25 pm, Chris Angelico <> wrote:
    > On Fri, Aug 17, 2012 at 12:27 PM, Steven D'Aprano
    >
    > <> wrote:
    > > There is already awesome protocols for running Python code remotely over
    > > a network. Please do not re-invent the wheel without good reason.

    >
    > > See pyro, twisted, rpyc, rpclib, jpc, and probably many others.

    >
    > But they're all tools for building protocols. I like to make
    > line-based protocols


    Dont know if this is relevant. If it is, its more in the heavyweight
    direction.
    Anyway just saw this book yesterday

    http://springpython.webfactional.com/node/39
     
    rusi, Aug 17, 2012
    #4
  5. On Fri, Aug 17, 2012 at 11:28 PM, Eric Frederich
    <> wrote:
    > Within the debugging console, after importing all of the bindings, there
    > would be no reason to import anything whatsoever.
    > With just the bindings I created and the Python language we could do
    > meaningful debugging.
    > So if I block the ability to do any imports and calls to eval I should be
    > safe right?


    Nope. Python isn't a secured language in that way. I tried the same
    sort of thing a while back, but found it effectively impossible. (And
    this after people told me "It's not possible, don't bother trying". I
    tried anyway. It wasn't possible.)

    If you really want to do that, consider it equivalent to putting an
    open SSH session into your debugging console. Would you give that much
    power to your application's users? And if you would, is it worth
    reinventing SSH?

    ChrisA
     
    Chris Angelico, Aug 17, 2012
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Eric Newton
    Replies:
    3
    Views:
    9,495
    Brock Allen
    Apr 4, 2005
  2. DataBinder.Eval and Eval.

    , Jun 16, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    564
    Karl Seguin [MVP]
    Jun 16, 2006
  3. keto
    Replies:
    0
    Views:
    1,001
  4. David Cournapeau

    print a vs print '%s' % a vs print '%f' a

    David Cournapeau, Dec 30, 2008, in forum: Python
    Replies:
    0
    Views:
    374
    David Cournapeau
    Dec 30, 2008
  5. Isaac Won
    Replies:
    9
    Views:
    404
    Ulrich Eckhardt
    Mar 4, 2013
Loading...

Share This Page