> > So in a view: <%= eval code.upc %> > > *DANGER DANGER DANGER* you are running with scissors here. If an > attacker can get arbitrary code into your database, using eval like > this will execute that code in the context of your application. > > You may want to read up on Kernel#eval, Object#instance_eval, and the > other forms of eval in Ruby, they're a lot of fun. But in this case, I > think they may not be the best choice if you can avoid them. > > -Michael > I've wondered about doing something like this myself, but in a different context...
Suppose I develop a generic RoR application that I would like to be able extend or customize on the fly. As an example, suppose I wanted records in my database with a certain value for the "from" field to always be stored in upper case, but I didn't (and can't) know at the time I develop the application to which values that rule (or some other totally arbitrary rule) would apply. I have thought about creating a table for Ruby code, and evaluating that code a key points in the execution of my application. I would restrict access to that table to admin users only, so as to reduce the risk of allowing malicious code into my database. So far, I haven't gotten anywhere other than wondering whether I really want to go down this path or not, and wondering how I might do so if I did want to start down that slippery slope. I'm curious -- have others had similar wonderments and address them similarly or differently? --wpd --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
