change_headers_on_each_request, it's a nice to have security enhancement but not crucial. If you are curious, you can check how we manage the tokens and batch requests
Yes! But you will need to enable the support of separate routes for standard Devise. So do something like this:
DeviseTokenAuth.setup do |config|config.enable_standard_devise_support = trueend
Rails.application.routes.draw do# standard devise routes available at /users# NOTE: make sure this comes first!!!devise_for :users# token auth routes available at /api/v1/authnamespace :api doscope :v1 domount_devise_token_auth_for 'User', at: 'auth'endendend
Some users have been experiencing issues with using this gem alongside standard Devise, with the
config.enable_standard_devise_support = true method.
Another method suggested by jotolo is to have separate child
application_controller.rb files that use either DeviseTokenAuth or standard Devise, which all inherit from a base
application_controller.rb file. For example, you could have an
api/v1/application_controller.rb file for the API of your app (which would use Devise Token Auth), and a
admin/application_controller.rb file for the full stack part of your app (using standard Devise). The idea is to redirect each flow in your application to the appropriate child
application_controller.rb file. Example code below:
Child application controller for your API, using DeviseTokenAuth.
module Apimodule V1class ApplicationController < ::ApplicationControllerskip_before_action :verify_authenticity_tokeninclude DeviseTokenAuth::Concerns::SetUserByTokenendendend
Child application controller for full stack section, using standard Devise.
module Adminclass ApplicationController < ::ApplicationControllerbefore_action :authenticate_admin!endend
The base application controller file. If you're using CSRF token protection, you can skip it in the API specific application controller (
class ApplicationController < ActionController::Baseprotect_from_forgery with: :exceptionend
enable_standard_devise_support configuration commented out or set to
# config.enable_standard_devise_support = false
new routes will require significant modifications to devise. If the inclusion of the
new routes is causing your app any problems, post an issue in the issue tracker and it will be addressed ASAP.
For some odd reason, ActiveAdmin extends from your own app's
ApplicationController. This becomes a problem if you include the
DeviseTokenAuth::Concerns::SetUserByToken concern in your app's
The solution is to use two separate
ApplicationController classes - one for your API, and one for ActiveAdmin. Something like this:
# app/controllers/api_controller.rb# API routes extend from this controllerclass ApiController < ActionController::Baseinclude DeviseTokenAuth::Concerns::SetUserByTokenend# app/controllers/application_controller.rb# leave this for ActiveAdmin, and any other non-api routesclass ApplicationController < ActionController::Baseend
You may be interested in solidus_devise_token_auth.
First, remove the migration generated by the following command
rails g devise_token_auth:install [USER_CLASS] [MOUNT_PATH] and then:.
Create another fresh migration:
# create migration by running a command like this (where `User` is your USER_CLASS table):# `rails g migration AddTokensToUsers provider:string uid:string tokens:text`def upadd_column :users, :provider, :string, null: false, default: 'email'add_column :users, :uid, :string, null: false, default: ''add_column :users, :tokens, :text# if your existing User model does not have an existing **encrypted_password** column uncomment below line.# add_column :users, :encrypted_password, :null => false, :default => ""# the following will update your models so that when you run your migration# updates the user table immediately with the above defaultsUser.reset_column_information# finds all existing users and updates them.# if you change the default values above you'll also have to change them here below:User.find_each do |user|user.uid = user.emailuser.provider = 'email'user.save!end# to speed up lookups to these columns:add_index :users, [:uid, :provider], unique: trueenddef down# if you added **encrypted_password** above, add here to successfully rollbackremove_columns :users, :provider, :uid, :tokensend