> Koz: are you prepared to argue that Ruby shouldn't have private > methods at all because programmers can get around them with __send__? > I want to make a method private so other programmers don't do stupid > stuff. I want it to be one more thing in the way of writing insecure, > unreliable code. There's no such thing as bulletproof code, but if I > can add more padding without adding conceptual weight, I'm all for it.
No, my point is simply that whatever safety you think you're receiving by fixing this respond_to? block is no substitute for code review. While this is definitely strange behaviour and a little counter intuitive I can't imagine a situation where you'd actually have a security issue caused by this code. I find it hard to think a developer will be sitting in an irb session saying "does this respond_to? :foo" rather than looking at the source to that model to find the method they want :) If you'd like to submit a patch for respond_to to check the private / public status of methods defined by attributes, I'd be happy to apply it. > -Gaius > > On Wed, Sep 3, 2008 at 12:27 PM, acechase <[EMAIL PROTECTED]> wrote: >> >> This is slightly tangential, but since we're on the subject, I'd like >> to point out a related issue with private methods. It's early, and I'm >> still working on my first cup of coffee, so please just ignore me if >> I'm too off topic here :). The problem I am seeing is that a private >> method works as expected when called directly on an object, but when >> the object is accessed through an association_proxy 'private' is >> ignored (because the association_proxy is 'send'ing on >> method_missing). >> >> Here's an example: >> >> Class User < AR::Base >> private >> def secret_stuff ; "foo" end >> end >> >> Class Purchase < AR::Base >> has_one :user >> end >> >>>> User.first.secret_stuff >> => NoMethodError: private method `secret_stuff' called for #<User: >> 0x3d446dc> # as expected >>>> Purchase.first.user.secret_stuff >> => "foo" # d'oh! >> >> Because the association_proxy does a blind send, the privacy check is >> bypassed. When I first came across this, it really threw me for a loop >> -- in one context my 'private' declaration was working fine and dandy, >> and in another, it was being ignored! I wanted to use 'private' >> because I had just modified my class in such a way that it made sense, >> encapsulation-wise, to only have the class itself access the >> particular method. I wasn't looking for true protection against >> malicious code, I just wanted to verify my encapsulation properties >> and find code that was violating those properties. In the end I >> decided it wasn't worth the effort to make the two code paths behave >> the same so instead I did a manual code comb to find outside classes >> who were accessing my private method. >> >> So, I guess I'm just offering this as another data point. It's another >> place where the rails metaprogramming slightly modifies the expected >> behavior of the underlying code. I don't think this is a major problem >> or anything, just thought it fit in with the current topic. Maybe this >> behavior is covered in the docs and I just missed it? >> >> Cheers, >> acechase >> >> On Sep 3, 12:37 am, "Michael Koziarski" <[EMAIL PROTECTED]> wrote: >>> > No, sorry. I'm trying to _truly_ make an attribute private. I want >>> > nobody but my instance (self) to be able to access this attribute. >>> > There's nothing like attr_private to my knowledge, though, so I >>> > declared private methods. >>> >>> I'd question *why* you want that to be completely private, what is it >>> you're hoping to achieve. Users of your code will *always* be able to >>> call your method, there's simply no way for you to stop them: >>> >>> @object.__send__(:your_secret_method) # PWN3D!!!! >>> >>> There's currently no way to mark an attribute as private, and we could >>> probably add that as an enhancement, but I'm a little confused what >>> the use case is. >>> >>> -- >>> Cheers >>> >>> Koz >> > >> > > > > -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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-core?hl=en -~----------~----~----~----~------~----~------~--~---
