acechase: I think your case is different, but extremely close to the issue I'm getting at. Thank you for bringing it up.
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. Also, I'd just like Rails Models to act like normal Ruby Objects. -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 > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
