I have a special url which I would want only few people to have access to. I have a list of super users stored as an array in the app.yml. How can I use this array in :requirements section of a specific route in the routes.rb file to allow only those super users access to this route? Thanks a lot.
No, you can't. :requirements are related to route parameters only.
Which is, in my opinion, a good thing. It's a well known convention to have authentication logic in controllers.
Like Pedro said.. authentication logic should be in controller code.
Take a look at before_filters, where you specify methods that will be called before (all or specified) actions in a controller are run. You can use such a method to deny actions from running. Look for the section named Filter Chain Halting here
:requirements is for specifying constraints for parts of the URL for the route to match. Usually regular expressions are specified as shown here.
map.geocode 'geocode/:postalcode', :controller => 'geocode',
:action => 'show', :requirements => { :postalcode => /\d{5}(-\d{4})?/ }
Related
I've noticed that when defining routes in the routes.rb file, you can actually access the same controller#action you defined in a different way.
For example:
map.connect "post/show/:id/:tag_title", :controller => "post", :action => "show", :requirements => {:id => /\d+/}
This means you can access post#show by going to
server.com/post/show/1234/tag_title-whatever
But you can also access post#show by going to
server.com/post/show?id=1234&tag_title=tag_title-whatever
It's a simple case, but you get the idea. Wouldn't this cause problems with search engines? If I'm not wrong, those 2 urls could potentially be taken as duped pages.
Is there a way to prevent this, like telling Rails to access the defined routes only the way they're defined?
Being able to access something doesn't mean that it will be indexed by Google. All Rails helper functions use the /post/show/.. links unless told differently. As long as you don't link to the specified resource, the likelihood of Google spidering the content is very slim.
That being said, I'm not even sure it would matter if they did end up indexing it.
I want the following urls for my UserController:
localhost/user/join
localhost/user/login
localhost/user/user_name (this can be any name in here, it should fire the 'profile' action)
Then within the /user/user_name_here/ folder I want:
/user/user_name/blah1/
/user/user_name/blah2/
/user/user_name/blah3/
It seems doing resources :user only creates things for index/show/get, so I'm confused as to how to do this other than creating so many match '/user/join' etc. lines in routes.
match "user/:user_name" => "users#show"
then /user/username will redirect to the User controller, call the show method, and pass the :user_name param
you could do the same to other actions that doesn't neet parameters,
match '/user/login' => "sessions#new"
match '/user/join' => "user#new"
Yup - 'resources :user' is just scaffolding for the usual CRUD methods. If you want paths additional to those, you're going to have to create routes (it's the only way your app knows how to route a given URL to a given controller and method).
The friendly_id gem does something similar to what you're suggesting (though I believe it's monkey-patching the .find method on ActiveRecords classes rather than handling routing specifically).
I've recently joined the world of Rails app development (Rails3) and I may be abusing resourceful routing.
The default resourceful routing makes some really convenient helper methods for the URLs which I use constantly. My problem is that I have controllers that I specified the routing as resourceful simply to take advantage of those helper methods. I have some basic site navigation that has no business with resources.
resource :home do
member do
get 'main'
get 'about'
get 'login'
get 'help'
end
end
Is there a better way to do what I've been doing? Anything that doesn't require that I manually add routing entries each time I have a new controller action?
Just to clarify, I want to specify routing for a controller without having to explicitly add any new actions but I also want it to auto-generate helper methods. So far, I have to explicitly add routes for each action I want that for. I can get something similar by doing this (in a non-resourceful way),
match 'home/about' => 'home#about'
But I don't want to have to write that very every route that doesn't fall into the convention.
Here's another simpler one. Just add a generic route to the bottom of your routes.rb
match ":controller/:action"
and it will map directly to the specified action of the specified controller. You can be a bit more specific if you like. For example, using get instead of match to restrict to HTTP GET requests, specifying the applicaple controllers etc.
get ":controller/:action", :constraints => { :controller => /home|help/ }
You can look into your controller for public instance methods and generate routes automatically.
# routes.rb
HomeController.public_instance_methods(false).select{|m| !(m.to_s =~ /^_/)}.each do |m|
match "home/#{m}", :action => m, :controller => HomeController, :as => "home_#{m}"
end
This will take the explicit(non-inherited) public instance methods from your controller, and select the ones that don't begin with an underscore(because underscored ones are generated methods for filters, the rest are actual actions). Then it will generate a named route for each.
Keep in mind that routes.rb is processed only at server startup so you will have to restart the server after you add new actions.
When should one use named routes vs. using url_for with a {:controller => "somecontroller", :action => "someaction"} hash?
Is one preferred over the other and why? Is one more maintainable or more efficient w.r.t. performance?
It might help to understand what named routes are doing.
Defining a Named route creates a wrapper around url_for providing the options required for the created route. Routing resources creates many named routes.
With that in mind, the overhead of calling a named route as opposed to url_for with the options needed is negligible. So if you're linking to a specific resource, named routes are the way to go. They're easier to read, type and maintain.
However, don't discount url_for. It has many creative uses thanks to the way it handles missing options. It is very useful when it comes to keeping views DRY that are used from multiple nested sources. Ie: when you have a blog_posts controller and posts_controller sharing the same views.
I strongly encourage you to read the url_for documentation. To help figure out where those places it makes sense to use url_for are.
I would prefer named routes as it's shorter and does the same thing.
named route is very neat.
map.with_options :controller => "company", :action => "show", :panel => "name" do |m|
m.company '/company/:action/:id/:panel'
end
Then you can call
company_url :id => 1
If you set up your routes and resources carefully, you shouldn't need any hash routes, only named ones (either built-in via map.resource or custom map.<something> ). Hash routes are useful, if you have to create links based on dynamic content. Something like:
link_to #post.title, :controller => (#user.is_admin ? 'admin/posts' : 'public/posts'), :action => 'show', :id => #post
(This is just a forced example, but you should get the gist of it :)
I've got a RESTful setup for the routes in a Rails app using text permalinks as the ID for resources.
In addition, there are a few special named routes as well which overlap with the named resource e.g.:
# bunch of special URLs for one off views to be exposed, not RESTful
map.connect '/products/specials', :controller => 'products', :action => 'specials'
map.connect '/products/new-in-stock', :controller => 'products', :action => 'new_in_stock'
# the real resource where the products are exposed at
map.resources :products
The Product model is using permalink_fu to generate permalinks based on the name, and ProductsController does a lookup on the permalink field when accessing. That all works fine.
However when creating new Product records in the database, I want to validate that the generated permalink does not overlap with a special URL.
If a user tries to create a product named specials or new-in-stock or even a normal Rails RESTful resource method like new or edit, I want the controller to lookup the routing configuration, set errors on the model object, fail validation for the new record, and not save it.
I could hard code a list of known illegal permalink names, but it seems messy to do it that way. I'd prefer to hook into the routing to do it automatically.
(controller and model names changed to protect the innocent and make it easier to answer, the actual setup is more complicated than this example)
Well, this works, but I'm not sure how pretty it is. Main issue is mixing controller/routing logic into the model. Basically, you can add a custom validation on the model to check it. This is using undocumented routing methods, so I'm not sure how stable it'll be going forward. Anyone got better ideas?
class Product < ActiveRecord::Base
#... other logic and stuff here...
validate :generated_permalink_is_not_reserved
def generated_permalink_is_not_reserved
create_unique_permalink # permalink_fu method to set up permalink
#TODO feels really ugly having controller/routing logic in the model. Maybe extract this out and inject it somehow so the model doesn't depend on routing
unless ActionController::Routing::Routes.recognize_path("/products/#{permalink}", :method => :get) == {:controller => 'products', :id => permalink, :action => 'show'}
errors.add(:name, "is reserved")
end
end
end
You can use a route that would not otherwise exist. This way it won't make any difference if someone chooses a reserved word for a title or not.
map.product_view '/product_view/:permalink', :controller => 'products', :action => 'view'
And in your views:
product_view_path(:permalink => #product.permalink)
It's a better practice to manage URIs explicitly yourself for reasons like this, and to avoid accidentally exposing routes you don't want to.