I need to change a little method in rails, specifically the
authorization method in ActionController::HttpAuthentication::Basic
(which uses a fixed list of authentication env locations that doesn''t
include what my server does).
Right now the way i do it is i have at the end of my application.rb file
module ActionController::HttpAuthentication::Basic
def authorization
#code here...
end
end
Is there a better way of doing it?
--
Posted via http://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
Sam Clearman wrote:> Right now the way i do it is i have at the end of my application.rb file > > module ActionController::HttpAuthentication::Basic > def authorization > #code here... > end > end > > Is there a better way of doing it?That looks like a standard Monkey Patch. Got unit tests for it? -- Phlip --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Phlip wrote:> Sam Clearman wrote: > >> Right now the way i do it is i have at the end of my application.rb file >> >> module ActionController::HttpAuthentication::Basic >> def authorization >> #code here... >> end >> end >> >> Is there a better way of doing it? > > That looks like a standard Monkey Patch. > > Got unit tests for it? > > -- > Phliphehe... nope. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Sam Clearman wrote:>>> Is there a better way of doing it? >> That looks like a standard Monkey Patch. >> >> Got unit tests for it?> hehe... nope.Ordinarily, the correct way to do anything - especially an MP - is to unit test it. However, in the case of Basic Authentication, you would need to mock the server... and the authorizer... and so on. The mocks would generally tell your test what they think it wants to hear, and you''d be back to square one. So maybe the question how to monkey-patch something is isomorphic to the question how you reasonably test it. Just make the monkey patch as small as possible, and then submit it to the maintainers... C-: -- Phlip --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hi -- On Thu, 6 Mar 2008, Phlip wrote:> > Sam Clearman wrote: > >>>> Is there a better way of doing it? >>> That looks like a standard Monkey Patch. >>> >>> Got unit tests for it? > >> hehe... nope. > > Ordinarily, the correct way to do anything - especially an MP - is to unit test it. > > However, in the case of Basic Authentication, you would need to mock the > server... and the authorizer... and so on. The mocks would generally tell your > test what they think it wants to hear, and you''d be back to square one. > > So maybe the question how to monkey-patch something is isomorphic to the > question how you reasonably test it.It''s possible to write your model classes inside a view, and then test them, but I still wouldn''t recommend it :-) I''m all for testing, but I don''t think that discussing best practices in other terms has been discredited. Also, there are tests for this class already, which could probably be adapted (depending what the new version is doing, of course). David -- Upcoming Rails training from David A. Black and Ruby Power and Light: ADVANCING WITH RAILS, April 14-17 2008, New York City CORE RAILS, June 24-27 2008, London (Skills Matter) See http://www.rubypal.com for details. Berlin dates coming soon! --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hi -- On Fri, 7 Mar 2008, Sam Clearman wrote:> > I need to change a little method in rails, specifically the > authorization method in ActionController::HttpAuthentication::Basic > (which uses a fixed list of authentication env locations that doesn''t > include what my server does). > > Right now the way i do it is i have at the end of my application.rb file > > module ActionController::HttpAuthentication::Basic > def authorization > #code here... > end > end > > > Is there a better way of doing it?(Written under protest, because you''re making me respond to the loathsome phrase "monkey patching" :-) Off-hand it looks to me like that might be happier living in the config/initializers directory, assuming you''re using 2.0 and that putting it there would have the same effect. It feels a bit buried in application.rb, whereas if it were in its own file in initializers, it would be more on the surface of the code and easier to find and/or notice. David -- Upcoming Rails training from David A. Black and Ruby Power and Light: ADVANCING WITH RAILS, April 14-17 2008, New York City CORE RAILS, June 24-27 2008, London (Skills Matter) See http://www.rubypal.com for details. Berlin dates coming soon! --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
David A. Black wrote:> It''s possible to write your model classes inside a view, and then test > them, but I still wouldn''t recommend it :-) I''m all for testing, but I > don''t think that discussing best practices in other terms has been > discredited. Also, there are tests for this class already, which could > probably be adapted (depending what the new version is doing, of > course).You are answering the question "how can I use tests to help bad designs live longer?" That''s a valid question and answer, but it''s non-responsive to my point. The goal, if you _must_ Monkey Patch, is to slightly increase the odds of a clear diagnostic error message when the real library upgrades out from under the patch. -- Phlip http://assert2.rubyforge.org/ --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hi -- On Sat, 8 Mar 2008, Phlip wrote:> > David A. Black wrote: > >> It''s possible to write your model classes inside a view, and then test >> them, but I still wouldn''t recommend it :-) I''m all for testing, but I >> don''t think that discussing best practices in other terms has been >> discredited. Also, there are tests for this class already, which could >> probably be adapted (depending what the new version is doing, of >> course). > > You are answering the question "how can I use tests to help bad > designs live longer?"No, neither asking nor answering that question :-) I just mean that I don''t think that "Can you write a ''reasonable'' test suite for it?" is the beginning and end of all examination of whether a given practice is a good one. Among other things, test suites are constrained by test tools, the current state of which I admire greatly but which are themselves subject to change and modification. I think one has to take all of this into account. That''s all I mean.> That''s a valid question and answer, but it''s non-responsive to my > point. > > The goal, if you _must_ Monkey Patch, is to slightly increase the odds > of a clear diagnostic error message when the real library upgrades out > from under the patch.Sure, but that''s true of all your code. I don''t like to stigmatize code that does something to the framework itself, which, like all other code, can be good or bad, well-maintained or not, etc. The adoption of the term "monkey patch" over the last couple of years is, I think, unfortunate, since it does tend to stigmatize practices that in many cases are perfectly reasonable and rational. In short, I don''t literally append "... but you have to do it well and make sure it works" to everything I say about Ruby, Rails, or software in general, but I think it''s kind of understood to be implied :-) David> -- > Phlip > http://assert2.rubyforge.org/ > >-- Upcoming Rails training from David A. Black and Ruby Power and Light: ADVANCING WITH RAILS, April 14-17 2008, New York City CORE RAILS, June 24-27 2008, London (Skills Matter) See http://www.rubypal.com for details. Berlin dates coming soon! --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---