这节主要集中在users资源上,主要内容为
1.用户自己可以编辑自己的信息。
2.对编辑信息做权限控制,必须先登录,而且编辑的是自己的资料
3.实现更友好的转向功能,例如登录论坛时回到登录前那一页,而不是论坛首页
4.列出所有用户时进行分页,不使得网页过于庞大。
5.设置管理员权限,并且管理员有权限删除其他用户
1.用户编辑自己的信息:
这个实现较简单,主要是编写用户编辑信息的表单,在action中实现edit和update功能,其中update要考虑提交失败与成功的情况。
<% provide(:title, "Edit user") %>
<h1>Update your profile</h1>
<div class="row">
<div class="span6 offset3">
<%= form_for(@user) do |f| %>
<%= render 'shared/error_messages' %>
<%= f.label :name %>
<%= f.text_field :name %>
<%= f.label :email %>
<%= f.text_field :email %>
<%= f.label :password %>
<%= f.password_field :password %>
<%= f.label :password_confirmation, "Confirm Password" %>
<%= f.password_field :password_confirmation %>
<%= f.submit "Save changes", class: "btn btn-large btn-primary" %>
<% end %>
<%= gravatar_for @user %>
<a href="http://gravatar.com/emails">change</a>
</div>
</div>
class UsersController < ApplicationController
.
.
.
def update
@user = User.find(params[:id])
if @user.update_attributes(user_params)
flash[:success] = "Profile updated"
redirect_to @user
else
render 'edit'
end
end
.
.
.
end
class UsersController < ApplicationController
.
.
.
def edit
@user = User.find(params[:id])
end
.
.
.
end
edit方法到了后面因为在过滤器中会生成@user变量,所以后面不再需要。 注意下列代码 <input name="_method" type="hidden" value="patch" />
因为浏览器本身并不支持发送 PATCH 请求(REST 动作要用),所以 Rails 就在 POST 请求中使用这个隐藏字段伪造了一个 PATCH 请求。还有一个细节需要注意一下,POST和PATCH都使用了相同的 form_for(@user) 来构建表单,那么 Rails 是怎么知道创建新用户要发送 POST 请求,而编辑用户时要发送 PATCH 请求的呢?这个问题的答案是,通过 Active Record 提供的 new_record? 方法可以检测用户是新创建的还是已经存在于数据库中的:
$ rails console>> User.new.new_record?
=> true
>> User.first.new_record?
=> false
2.对权限进行控制:
限制用户必须先登录才能更新自己的资料,而不能更新他人的资料。没有登录的用户如果试图访问这些受保护的页面,会转向登录页面,并显示一个提示信息。我们要使用 before_action 方法实现权限限制,这个方法会在指定的动作执行之前,先运行指定的方法。为了实现要求用户先登录的限制,我们要定义一个名为 signed_in_user 的方法,然后调用 before_action :signed_in_user
class UsersController < ApplicationController
before_action :signed_in_user, only: [:edit, :update]
.
.
.
private
def user_params
params.require(:user).permit(:name, :email, :password,
:password_confirmation)
end
# Before filters
def signed_in_user
redirect_to signin_url, notice: "Please sign in." unless signed_in?
end
end
这里只是实现了必须登录,但用户仍可以修改他人的资料。我们在控制器中加入了第二个事前过滤器,调用 correct_user 方法
before_action :correct_user, only: [:edit, :update]
def correct_user
@user = User.find(params[:id])
redirect_to(root_path) unless current_user?(@user)
end
同时需要定义current_user?方法
module SessionsHelper
.
.
.
def current_user
remember_token = User.encrypt(cookies[:remember_token])
@current_user ||= User.find_by(remember_token: remember_token)
end
def current_user?(user)
user == current_user
end
.
.
.
end
上述功能还有个缺陷:不管用户尝试访问的是哪个受保护的页面,登录后都会转向资料页面。也就是说,如果未登录的用户访问了编辑资料页面,会要求先登录,登录转到的页面是 /users/1,而不是 /users/1/edit。如果登录后能转到用户之前想访问的页面就更好了。加入下列代码:
module SessionsHelper
.
.
.
def redirect_back_or(default)
redirect_to(session[:return_to] || default)
session.delete(:return_to)
end
def store_location
session[:return_to] = request.fullpath if request.get?
end
end
地址的存储使用了 Rails 提供的 session,session 可以理解成cookies 是类似的东西,会在浏览器关闭后自动失效。我们还使用了 request 对象的 fullpath 方法获取了所请求页面的完整地址。在 store_location 方法中,把完整的请求地址存储在 session[:return_to] 中。但这个方法只能在 GET 请求中使用(if request.get?)。这么做,当未登录的用户提交表单时,不会存储转向地址(这种情况虽然很罕见,但在提交表单前,如果用户手动删除了记忆权标,还是会发生的),那么本来期望接收 POST、PATCH 或 DELETE 请求的动作实际收到的却是 GET 请求,就会产生异常。
要使用 store_location,我们要把它加入 signed_in_user 事前过滤器中
如下:
def signed_in_user
unless signed_in?
store_location
redirect_to signin_url, notice: "Please sign in."
end
end
再去修改session的create方法,
class SessionsController < ApplicationController
.
.
.
def create
user = User.find_by(email: params[:session][:email].downcase)
if user && user.authenticate(params[:session][:password])
sign_in user
redirect_back_or user
else
flash.now[:error] = 'Invalid email/password combination'
render 'new'
end
end
.
.
.
end
如果 session[:return_to] 的值不是 nil,上面这行代码就会返回 session[:return_to] 的值,否则会返回 default。注意,在上述代码中,成功转向后就会删除存储在 session 中的转向地址。如果不删除的话,在关闭浏览器之前,每次登录后都会转到存储的地址上。
至此,我们也就完成了基本的用户身份验证和页面保护机制。