To begin, we will pay attention to Rails 2.3.8 - many of you have heard about it, but not everyone knows what has changed there. By the way, the main innovations occurred in version 2.3.6, while .7 and .8 versions only corrected errors.
So, the list of changes is rather pleasant for me personally, I will not read it out completely, I will consider only the most interesting.
1. Reworked flash, it is recommended to use two basic types - alert and notice. And it can also be used with a redirect.
Here's how it was:
flash [ :notice ] = ' '
redirect_to @article
And how can you write now:
redirect_to ( @article, :notice => ' ' )
It is worth considering that if you have your own flash type, for example, flash [: error], then adding it to the redirect will not work.
2. For users of the MySQL database, a couple of very useful innovations have been added:
- Now you can specify the length of the index:
add_index ( :accounts , :name , :name => 'by_name' , :length => 10 )
# => CREATE INDEX by_name ON accounts(name(10))
add_index ( :accounts , [ :name , :surname ] , :name => 'by_name_surname' , :length =>
{ :name => 10 , :surname => 15 } )
# => CREATE INDEX by_name_surname ON accounts(name(10), surname(15))
- The add_ and change_column methods now support the parameter: first => true, and: after =>: column. Previously, it added new columns to the end of the table, and now you can explicitly indicate where to put them:
add_column :comments , :post_id , :integer , :first => true
3. If you use testing with standard rail tests, then new methods assert_blank and assert_present can help you. The first compares the object with an empty string, and the second checks its presence.
')
4. The function Object Object # presence is added, which returns the object itself, if it exists and is not an empty string, otherwise returns nil. And it is very convenient to choose one of various parameters (lovers of syntactic sugar are jubilant):
region = params [ :state ] . presence || params [ :country ] . presence || 'US'
5. An exclude? Method has been added to the Enumerable type, which is the countercompletion of the include? Method, and returns true if the specified object does not contain an element
array = [ 'foo' , 'bar' ]
array. exclude ? ( 'boo' ) # => true
array. exclude ? ( 'bar' ) # => false
Also, do not overlook a few interesting gems.
Sentient User [link]
Its purpose is quite simple - it allows current_user to be used in models. Someone will say that the models do not interfere with the methods of the controllers, but personally this gem was very useful to me when I prescribed various validations. Using it is very simple - just write “include SentientController” in your ApplicationController. Do not forget that if your authorization module does not support the current_user method, then you should create it yourself. There should be no problems on such popular mechanisms as Restful Authentication and Authlogic.
Request Rate Limiter [link]
If your application is not as small as it used to be, and the number of users is constantly growing, you should think about security. This plugin will protect against too frequent requests that can make not very friendly users (or possible competitors). Use no more difficult than the previous one:
# config/application.rb
require 'rack/throttle'
class Application < Rails::Application
config. middleware . use Rack::Throttle::Interval
end
Then we write down restrictions on requests:
use Rack::Throttle::Daily , :max => 1000 #
use Rack::Throttle::Hourly , :max => 100 #
use Rack::Throttle::Interval , :min => 3.0 #
You can also specify which storage to use — GDBM, Memcached, and Redis are supported.
However, this plugin is only available in
Rails 3.0+ , so it will only be relevant in the future, or if you are developing an application on a beta version of the rails.
This is a great way to limit the rights of users on your site.
The first thing we need to do is create an ability class, which we will save in models / ability.rb
class Ability
include CanCan::Ability
def initialize ( user )
if user. admin ?
can :manage , :all
else
can :read , :all
end
end
end
All permissions will be stored there.
Then, you can use it in view:
<% if can? :update , @article %>
<% = link_to "Edit" , edit_article_path ( @article ) %>
<% end %>
In the controller, you can use the authorize! Method, which will cause an exception if the user does not have rights to the action:
def show
@article = Article. find ( params [ :id ] )
authorize! :read , @article
end
The exception can be intercepted and processed, in our case, we notify the user about the lack of access using a flash and redirect:
class ApplicationController < ActionController::Base
rescue_from CanCan::AccessDenied do | exception |
# - redirect_to(root_url, :alert => exception.message)
flash [ :error ] = exception. message
redirect_to root_url
end
end
As you can see, there are no difficulties here, and you should not reinvent the wheel when all the good things have been thought up for you.
Materials from the documentation of the described plug-ins were used, and the plug-ins themselves were found on the Riding Rails website