Controller Integration
This gem includes a Rails concern called
DeviseTokenAuth::Concerns::SetUserByToken
. Include this concern to provide access to controller methods such as authenticate_user!
, user_signed_in?
, etc.It is recommended to include the concern in your base
ApplicationController
so that all children of that controller include the concern as well.# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
include DeviseTokenAuth::Concerns::SetUserByToken
end
Method | Description |
before_action :authenticate_user! | Returns a 401 error unless a User is signed-in. |
current_user | Returns the currently signed-in User , or nil if unavailable. |
user_signed_in? | Returns true if a User is signed in, otherwise false . |
devise_token_auth_group | |
update_auth_header | After action that updates the header with the new token, it's included by default, you should skip it if you are destroying the user |
Note that if the model that you're trying to access isn't called
User
, the helper method names will change. For example, if the user model is called Admin
, the methods would look like this:before_action :authenticate_admin!
admin_signed_in?
current_admin
# app/controllers/test_controller.rb
class TestController < ApplicationController
before_action :authenticate_user!
def members_only
render json: {
data: {
message: "Welcome #{current_user.name}",
user: current_user
}
}, status: 200
end
end
The authentication information should be included by the client in the headers of each request. The headers follow the RFC 6750 Bearer Token format:
"access-token": "wwwww",
"token-type": "Bearer",
"client": "xxxxx",
"expiry": "yyyyy",
"uid": "zzzzz"
The authentication headers (each one is a seperate header) consists of the following params:
param | description |
access-token | This serves as the user's password for each request. A hashed version of this value is stored in the database for later comparison. This value should be changed on each request. |
client | This enables the use of multiple simultaneous sessions on different clients. (For example, a user may want to be authenticated on both their phone and their laptop at the same time.) |
expiry | The date at which the current session will expire. This can be used by clients to invalidate expired tokens without the need for an API request. |
uid | A unique value that is used to identify the user. This is necessary because searching the DB for users by their access token will make the API susceptible to timing attacks. |
The authentication headers required for each request will be available in the response from the previous request. If you are using the ng-token-auth AngularJS module or the jToker jQuery plugin, this functionality is already provided.
Last modified 3yr ago