《Distributed Programming With Ruby》读书笔记二 Security and ID Conversion (Part1.1-2)

• • Security
  • • Although DRb provide some security, they fall short of a full, comprehensive solution. This can make DRb less than desirable in a lot of real world situations. However, in situations where security is a lesser concern,such as prototyping and intranet application.
    • Safe mode to disable all eval() related calls
    • 
    • • First, we retrieve a new remote object from the server. Then we undefine the instance_eval method on that remote object. Because of how DRb works, as we learned earlier, when a method does not exist on the local copy of the remote object, the method is invoked on the server side. So in the last line, when we call the instance_eval method and tell it to evaluate String "`rm -rf *`", we are telling the remote server to forcibly, and recursively, remove all files on the server.
      • It’s best to run your “server” code with a safe mode of at least 1: $SAFE = 1. This disables eval() and related calls on strings passed across the wire. Now, if you were to run our malicious client again, you would get the following error:
      • •     SecurityError: Insecure operation - instance_eval
      • comment：如何设置safe mode？ check netxt part(ACL)
    • Access Control Lists(ACLs）
    • 
    • • Only deny 192.168.1.7
      • • acl = ACL.new(%w{deny 192.168.1.7})
    • DRb over SSL（Secure Sockets Layer）
    • In its simplest form SSL works like this: The client makes an SSL request to the server. The server says, “Here is my public key. Use it to encrypt your request, and I, the server,will use my private key to decode it.”
    • There is an example on how do lock down our "Hello World" application to accept only trusted connections of SSL of this part. Details should check books.

             

• • • ID Conversion
    • • The method of looking up an object in the ObjectSpace using the reference ID is called ID conversion.
      • DRb ships with three built-in ID converters: DRb::DRbId-Conv, DRb::TimerIdConv, and DRb::GWIdConv. It is also possible to build your own ID converter.
      • Built-in ID Converters
      • • We only look at DRb::DRbIdConv and DRb::TimerIdConv. The general consensus on the DRb::GWIdConv converter is that it is extremely complicated to set up, prone to failure,and quite slow.
        • DRb::DRbIdConv
        • DRb::DRbIdConv is the default ID converter when dealing with DRb.The default ID converter, DRb::DRbId-Conv, simply uses the object_id for the object to determine its reference. That reference ID is then used to look up the object in the ObjectSpace and then invoke the requested message.
        • • example:
          • server
          • 
          • client
          • 
          • output
          • • client
            • 
            • server
            • 
          • As we can see, the object_id on the server printout matches the @ref instance variable on the DRbObject we received from the server. This is the default.
        • DRb::TimerIdConv
        • The default ID converter, DRb::DRbIdConv, has one downside. If you're not careful,referenced objects on the server can become garbage-collected and are no longer available when the client tries to reference them.
        • The only difference between DRb::TimerIdConv and DRb::DRbIdConv is that DRb::TimerIdConv tells the server to keep its objects alive for a certain amount of time after they were last accessed. The default length for this keepalive is 600 seconds,or 10 minutes.
        • • server
          • 
        • A better approach to solve the garbage-collection problem lies in your architecture.Don’t take an object from the server and hold onto it in the client for any longer than you absolutely need to. Retrieve the object from the server, use it, and then get rid of it. If you want to make sure you have access to that same referenced object minutes, hours, or days later, you should consider writing your own custom ID converter that stores your objects in something other than the ObjectSpace.
      • Building Your Own ID Converter
      • Why would we want to do that? Perhaps we want to have some sort of signature in the ID so that we can tell by looking at it where it originated. Perhaps we are using a database as our object store on the server, and we want to use the primary key for the database row as the ID. Or perhaps we just want to be different.
      • • Example: append HW: to the object_id for our objects so that we know that those objects came from the HelloWorldServer
        • change server code like:
        • 
        • client will output：
        • 
      • Using Multiple ID Converters
      • when you install a converter using the DRb.install_id_conv method, you tell DRb that all services in that Ruby VM are now to use that particular ID converter.
      • if you want to use multiple ID converters,the start_service method takes a third parameter, a Hash of configuration parameters. One parameter in the list of available parameters is :idconv, which tells DRb to use a particular ID converter for that service.
      • • modify server code to:
        • 
        • client
        • 
        • output
        • 

转载于:https://www.cnblogs.com/nightcatcher/p/6128096.html