# Instantiating controllers? **URL:** \ **Category:** Rails\ **Created:** [December 31, 2009, 7:14am UTC](https://www.ruby-forum.com/t/instantiating-controllers/180899 "2009-12-31T07:14:47Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![student](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ecc23a/32.png) [@student](https://www.ruby-forum.com/u/student)\ **Post date:** [December 31, 2009, 7:14am UTC](https://www.ruby-forum.com/t/instantiating-controllers/180899/1 "2009-12-31T07:14:47Z")
The problem: Application sidebar needs to be able to determine which links to display, based on which links a user can actually access. It is important that the interface be DRY, as this is a security matter. The proposed solution: For each controller, define an authorized? method, and a before filter to redirect users if it fails. For each link in the sidebar view, instantiate an appropriate controller object, complete with params, and call authorized? on it, displaying the link only if the response is true. The HELP: I really don’t see how to properly instantiate this controller. I really, REALLY don’t see how to do this in a rack framework. In fact, it looks to me that what I want is to tear apart the rack/rails boundary. ☹ – 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 removed\_email\_address@domain.invalid. To unsubscribe from this group, send email to removed\_email\_address@domain.invalid. For more options, visit this group at [http://groups.google.com/group/rubyonrails-talk?hl=en](http://groups.google.com/group/rubyonrails-talk?hl=en). ---
**Author:** ![student](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ecc23a/32.png) [@student](https://www.ruby-forum.com/u/student)\ **Post date:** [December 31, 2009, 10:42am UTC](https://www.ruby-forum.com/t/instantiating-controllers/180899/2 "2009-12-31T10:42:42Z")
Student Jr wrote: > The problem: Application sidebar needs to be able to determine which > links to display, based on which links a user can actually access. It > is important that the interface be DRY, as this is a security matter. DRY and security are orthogonal here. (And if it’s a security matter, make sure you consider the case where the user types in a URL of a page he’s not supposed to know about.) > The proposed solution: For each controller, define an authorized? > method, and a before filter to redirect users if it fails. For each > link in the sidebar view, instantiate an appropriate controller > object, complete with params, and call authorized? on it, displaying > the link only if the response is true. You should never need to do it this way, for the reasons given below. Anyway, this is asking too much of the controller (and it would be quite inefficient)…and this only works at controller granularity. What you might want to do is this: define your authorized? method on User so you can do if current\_user.authorized? :controller =\> ‘users’, :action =\> ‘delete’ # show link end You could then use this same method in a before\_filter in the controller itself. > The HELP: I really don’t see how to properly instantiate this > controller. I really, REALLY don’t see how to do this in a rack > framework. In fact, it looks to me that what I want is to tear apart > the rack/rails boundary. ☹ Controllers are automatically instantiated in Rails. You have no direct control over that, and needn’t worry about it. The framework will do the right thing. > – > > 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 removed\_email\_address@domain.invalid. > To unsubscribe from this group, send email to > removed\_email\_address@domain.invalid. > For more options, visit this group at > [http://groups.google.com/group/rubyonrails-talk?hl=en](http://groups.google.com/group/rubyonrails-talk?hl=en). ## Best, Marnen Laibow-Koser [http://www.marnen.org](http://www.marnen.org) removed\_email\_address@domain.invalid ---
**Author:** ![student](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ecc23a/32.png) [@student](https://www.ruby-forum.com/u/student)\ **Post date:** [December 31, 2009, 2:55pm UTC](https://www.ruby-forum.com/t/instantiating-controllers/180899/3 "2009-12-31T14:55:22Z")
Telling people about links that they aren’t supposed to be able to access sounds like a security issue to me. More centrally, however, is that the links may be more complicated than just [http://site/controller/action](http://site/controller/action). There can be any of a number of things in the params, including an id field, and the interpretation of these params can affect the results. But it is the target controller which must interpret these params. For instance, the target controller know which class is the class to use to interpret the id field. (Yes, I’m considering using this methodology more generally than just a sidebar.) On Dec 31, 3:42 am, Marnen Laibow-Koser [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > method, and a before filter to redirect users if it fails. For each > > > controller. I really, REALLY don’t see how to do this in a rack > > Groups “Ruby on Rails: Talk” group. > > – > > Posted viahttp://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 removed\_email\_address@domain.invalid. To unsubscribe from this group, send email to removed\_email\_address@domain.invalid. For more options, visit this group at [http://groups.google.com/group/rubyonrails-talk?hl=en](http://groups.google.com/group/rubyonrails-talk?hl=en). ---
**Author:** ![student](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ecc23a/32.png) [@student](https://www.ruby-forum.com/u/student)\ **Post date:** [December 31, 2009, 6:50pm UTC](https://www.ruby-forum.com/t/instantiating-controllers/180899/4 "2009-12-31T18:50:31Z")
Student Jr wrote: > Telling people about links that they aren’t supposed to be able to > access sounds like a security issue to me. Of course it is. That’s not what I said. And please don’t top-post. > More centrally, however, is that the links may be more complicated > than just [http://site/controller/action](http://site/controller/action). There can be any of a number > of things in the params, including an id field, and the interpretation > of these params can affect the results. Then send the whole url\_for params hash to authorize?. Easy. > But it is the target > controller which must interpret these params. For instance, the > target controller know which class is the class to use to interpret > the id field. Why does the id field need to get interpreted at this stage? Surely you’re not going to take each nav link and do a database query on the record it talks about at the time the navbar is created – that would be horribly inefficient! Just reject the user when he loads the controller tries to perform the action. Also take a look at rails\_authorization\_plugin. > (Yes, I’m considering using this methodology more generally than just > a sidebar.) Design for what you actually have now, not uncertain future requirements. You can always refactor later. YAGNI. > On Dec 31, 3:42�am, Marnen Laibow-Koser [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > > method, and a before filter to redirect users if it fails. �For each > > > > > controller. �I really, REALLY don’t see how to do this in a rack > > > Groups “Ruby on Rails: Talk” group. > > > – > > > Posted viahttp://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 removed\_email\_address@domain.invalid. > To unsubscribe from this group, send email to > removed\_email\_address@domain.invalid. > For more options, visit this group at > [http://groups.google.com/group/rubyonrails-talk?hl=en](http://groups.google.com/group/rubyonrails-talk?hl=en). ---
**Author:** ![student](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ecc23a/32.png) [@student](https://www.ruby-forum.com/u/student)\ **Post date:** [December 31, 2009, 8:46pm UTC](https://www.ruby-forum.com/t/instantiating-controllers/180899/5 "2009-12-31T20:46:33Z")
On Dec 31, 11:50 am, Marnen Laibow-Koser [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > More centrally, however, is that the links may be more complicated > > than justhttp://site/controller/action. There can be any of a number > > of things in the params, including an id field, and the interpretation > > of these params can affect the results. > > Then send the whole url\_for params hash to authorize?. Easy. Thing is, url\_for holds a lot of default information. It would appear that I would need to walk ActionController::UrlRewriter#rewrite\_url. Doable, but messy. (Also fragile, if Rails changes) > > But it is the target > > controller which must interpret these params. For instance, the > > target controller know which class is the class to use to interpret > > the id field. > > Why does the id field need to get interpreted at this stage? Surely > you’re not going to take each nav link and do a database query on the > record it talks about at the time the navbar is created – that would be > horribly inefficient! Just reject the user when he loads the controller > tries to perform the action. No, the current\_user object will cache any data of that sort. The idea is to not even show the link in the first place. > Also take a look at rails\_authorization\_plugin. I’ll see if there is anything stealable there. > > (Yes, I’m considering using this methodology more generally than just > > a sidebar.) > > Design for what you actually have now, not uncertain future > requirements. You can always refactor later. YAGNI. I do have it now, the question is how far I can take the methodology. If I only had controller/action - type links, then I would have defined stuff at the class level & been done. – 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 removed\_email\_address@domain.invalid. To unsubscribe from this group, send email to removed\_email\_address@domain.invalid. For more options, visit this group at [http://groups.google.com/group/rubyonrails-talk?hl=en](http://groups.google.com/group/rubyonrails-talk?hl=en). ---
**Author:** ![student](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ecc23a/32.png) [@student](https://www.ruby-forum.com/u/student)\ **Post date:** [December 31, 2009, 7:46pm UTC](https://www.ruby-forum.com/t/instantiating-controllers/180899/6 "2009-12-31T19:46:16Z")
I am not sure I know exactly what you mean, but just a suggestion to DRY the thing: use inheritance of controllers and define the before\_filter there. Then I would suggest using partial for the bar and include it in a layout. And since the actions are different for each controller, i would suggest just a minimal type of controller method returning just array of symbols like [:create, :settings, …] … keeping the rendering and all the other stuff as a responsibility of view and helpers. good luck! On Dec 31, 2:53 pm, Student [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > is important that the interface be DRY, as this is a security matter. > > > the right thing. > > > ## Best, > > > > ## Marnen Laibow-Koserhttp://www.marnen.org removed\_email\_address@domain.invalid > > > > Posted viahttp://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 removed\_email\_address@domain.invalid. To unsubscribe from this group, send email to removed\_email\_address@domain.invalid. For more options, visit this group at [http://groups.google.com/group/rubyonrails-talk?hl=en](http://groups.google.com/group/rubyonrails-talk?hl=en).