Distributed Ruby method_missing NameError == boo (test case included)

ruby-talk
1

Hi.

Distributed ruby seems to have issue with dispatch doen via
method_missing on the remote side. Is there a possible workaround for
this..

Here is a little test case that demonstrates the issue

···

#
# DRb method_missing test
#

class Tom
  def bloop
    puts "TOM GOES BLOOP"
    return %w{h a t s a r e f u n}
  end
  def method_missing(method,*args)
    puts "TOM :: method_missing #{method}"
  end
end

class MMObject
  def initialize()
    @tom = Tom.new
  end

  def method_missing(method,*args)
    @tom.send(method)
  end
end
URI = 'druby://localhost:9000'
def server
  mmObject = MMObject.new
  DRb.start_service(URI, mmObject)
  DRb.thread.join # Don't exit just yet!
end

def client
  DRb.start_service()
  mmObject = DRbObject.new(nil,URI)
  mmObject.bloop
  mmObject.whatever
end

require 'drb'

if __FILE__ == $0
  begin
  if not ARGV.nil? and ARGV.size == 1
      send(ARGV[0])
  else
    raise "No Argument"
  end
  rescue
      puts $!.message
      puts "To Use this run with argument:
       'server' to launch server instance
       'client' to launch client instance
         (which connects to server instance)
      "
  end
end

2

This is by design, see #check_insecure_method. DRb only lets you call public methods an object responds to.

DRb will let you call the method if you define #respond_to? correctly.

Beware the security implications of this.

require 'drb'

URI = 'druby://localhost:9000'

class MM
   def method_missing(method, *args) puts "called #{method}" end
   def respond_to?(method) method == :bloop end
end

case ARGV.first
when 'client'
   DRb.start_service
   mm = DRbObject.new nil, URI
   mm.bloop
   mm.whatever
when 'server'
   DRb.start_service URI, MM.new
   trap('INT') { DRb.thread.kill; exit }
   DRb.thread.join
else
   STDERR.puts "#{$0} client|server"
end

···

On 26 May 2005, at 08:05, curtis.schofield@gmail.com wrote:

Hi.

Distributed ruby seems to have issue with dispatch doen via
method_missing on the remote side. Is there a possible workaround for
this..

--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

3

Beautiful. Thank for the complete info. I was thinking about how
respond_to must be playing a role, i think i can use this in a
resonably secure manner.

thanks!