我的Rails应用程序使用Devise进行身份验证。它有一个姐妹iOS应用程序,用户可以使用与该Web应用程序相同的凭据登录到iOS应用程序。所以我需要某种API进行身份验证。
这里有许多类似的问题指向本教程,但它似乎token_authenticatable已过时,因为此模块已从Devise中删除,并且某些行会引发错误。(我使用的是Devise 3.2.2。)我曾尝试根据该教程(和本教程)推出自己的教程,但我对此并不百分百自信- 我觉得可能有些东西被误解或错过。
token_authenticatable
首先,按照这个要点的建议,我authentication_token在users表中添加了text属性,以下内容添加到user.rb:
authentication_token
users
user.rb
before_save :ensure_authentication_token def ensure_authentication_token if authentication_token.blank? self.authentication_token = generate_authentication_token end end private def generate_authentication_token loop do token = Devise.friendly_token break token unless User.find_by(authentication_token: token) end end
然后,我有以下控制器:
api_controller.rb
class ApiController < ApplicationController respond_to :json skip_before_filter :authenticate_user! protected def user_params params[:user].permit(:email, :password, :password_confirmation) end end
(请注意,我application_controller有一行before_filter :authenticate_user!。)
application_controller
before_filter :authenticate_user!
api / sessions_controller.rb
class Api::SessionsController < Devise::RegistrationsController prepend_before_filter :require_no_authentication, :only => [:create ] before_filter :ensure_params_exist respond_to :json skip_before_filter :verify_authenticity_token def create build_resource resource = User.find_for_database_authentication( email: params[:user][:email] ) return invalid_login_attempt unless resource if resource.valid_password?(params[:user][:password]) sign_in("user", resource) render json: { success: true, auth_token: resource.authentication_token, email: resource.email } return end invalid_login_attempt end def destroy sign_out(resource_name) end protected def ensure_params_exist return unless params[:user].blank? render json: { success: false, message: "missing user parameter" }, status: 422 end def invalid_login_attempt warden.custom_failure! render json: { success: false, message: "Error with your login or password" }, status: 401 end end
api / registrations_controller.rb
class Api::RegistrationsController < ApiController skip_before_filter :verify_authenticity_token def create user = User.new(user_params) if user.save render( json: Jbuilder.encode do |j| j.success true j.email user.email j.auth_token user.authentication_token end, status: 201 ) return else warden.custom_failure! render json: user.errors, status: 422 end end end
并在 config / routes.rb中 :
namespace :api, defaults: { format: "json" } do devise_for :users end
我有点不合常理,而且我确定这里有些事会让我未来的自我回顾并畏缩(通常是这样)。一些困难的部分:
首先 ,您会注意到Api::SessionsControllerfrom的继承,Devise::RegistrationsController而from的Api::RegistrationsController继承ApiController(我还有其他一些控制器,例如Api::EventsController < ApiController用于处理其他模型的更多标准REST东西,而与Devise的联系并不多。)这是一个非常丑陋的安排,但我想不出另一种方法来访问所需的方法Api::RegistrationsController。我上面链接的教程的内容是include Devise::Controllers::InternalHelpers,但此模块似乎已在Devise的最新版本中删除。
Api::SessionsController
Devise::RegistrationsController
Api::RegistrationsController
ApiController
Api::EventsController < ApiController
include Devise::Controllers::InternalHelpers
其次 ,我禁用了该线路的CSRF保护skip_before_filter :verify_authentication_token。我对这是否是一个好主意感到怀疑-我看到关于JSON API是否易受CSRF攻击的许多冲突或难以理解的建议-但添加这一行是我使该死的事情起作用的唯一方法。
skip_before_filter :verify_authentication_token
第三 ,我想确保我了解用户登录后身份验证的工作原理。假设我有一个API调用GET /api/friends,该调用返回了当前用户的朋友列表。据我了解,iOS应用程序必须authentication_token从数据库中获取用户的信息(这是每个用户永远不变的固定值?),然后将其作为参数与每个请求一起提交,例如GET /api/friends?authentication_token=abcdefgh1234,那么我Api::FriendsController可以就像User.find_by(authentication_token: params[:authentication_token])获得current_user一样。真的这么简单吗,还是我错过了什么?
GET /api/friends
GET /api/friends?authentication_token=abcdefgh1234
Api::FriendsController
User.find_by(authentication_token: params[:authentication_token])
因此,对于所有设法阅读完这个庞然大物的人来说,谢谢您的宝贵时间!总结一下:
谢谢!
您不想禁用CSRF,我已经读到人们认为出于某种原因它不适用于JSON API,但这是一种误解。要使其保持启用状态,您需要进行一些更改:
在服务器端,将一个after_filter添加到您的会话控制器中:
after_filter :set_csrf_header, only: [:new, :create]
protected
def set_csrf_header response.headers[‘X-CSRF-Token’] = form_authenticity_token end
这将生成一个令牌,将其放入您的会话中,并将其复制到所选操作的响应标头中。
客户端(iOS),您需要确保已完成两件事。
您的客户端需要扫描所有服务器响应以查找此标头,并在传递时保留它。
... get ahold of response object
// response may be a NSURLResponse object, so convert: NSHTTPURLResponse httpResponse = (NSHTTPURLResponse)response; // grab token if present, make sure you have a config object to store it in NSString *token = [[httpResponse allHeaderFields] objectForKey:@”X-CSRF-Token”]; if (token) [yourConfig setCsrfToken:token];
最后,您的客户需要将此令牌添加到它发出的所有“非GET”请求中:
... get ahold of your request object
if (yourConfig.csrfToken && ![request.httpMethod isEqualToString:@”GET”]) [request setValue:yourConfig.csrfToken forHTTPHeaderField:@”X-CSRF-Token”];
难题的最后一步是了解登录进行设计时,正在使用两个后续的session / csrf令牌。登录流程如下所示:
GET /users/sign_in -> // new action is called, initial token is set // now send login form on callback: POST /users/sign_in <username, password> -> // create action called, token is reset // when login is successful, session and token are replaced // and you can send authenticated requests