This is both an issue and a question in one:

Why do you include this in ActionController::Base and not ApplicationController?

This behavior doesn't allow for Rails API to use this gem without hacking at the source/including it in ActionController::API or ApplicationController.

The second downside is that, as far as I can tell Devise is adding it's methods to the ApplicationController as well, which is forcing you to reload the Devise Methods in ActionController::Base.

I might work on this weekend and perhaps send in a PR, but probably needs to be changed regardless if i'm right. Feel free to let me know if I'm totally off the mark though.

I've read this #67
I've done this

1. config.sign_in_token = false

2. acts_as_token_authentication_handler_for User, fallback_to_devise: false

Once I do this, I'm able to access any controller without any token provided. It's basically like authentication doesn't exist.

If I don't include fallback_to_devise: false, I get undefined method `authenticate_user!' on every request.
I've read this #42
Yes my User model is setup for devise and I've installed devise.

I'm trying to create an app which is purely an API like explained in issue 67. Feels like I'm missing something major. Thanks in advance for any help.

Here are some relevant files that should help with troubleshooting

class User < ActiveRecord::Base
  acts_as_token_authenticatable
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :trackable, :validatable
end

class ApplicationController < ActionController::Base
  # Prevent CSRF attacks by raising an exception.

  protect_from_forgery with: :null_session#, :if => Proc.new { |c| c.request.format == 'application/json' }

  acts_as_token_authentication_handler_for User, fallback_to_devise: false

end

SimpleTokenAuthentication.configure do |config|

  # Configure the session persistence policy after a successful sign in,
  # in other words, if the authentication token acts as a signin token.
  # If true, user is stored in the session and the authentication token and
  # email may be provided only once.
  # If false, users must provide their authentication token and email at every request.
  config.sign_in_token = false

  # Configure the name of the HTTP headers watched for authentication.
  #
  # Default header names for a given token authenticatable entity follow the pattern:
  #   { entity: { authentication_token: 'X-Entity-Token', email: 'X-Entity-Email'} }
  #
  # When several token authenticatable models are defined, custom header names
  # can be specified for none, any, or all of them.
  #
  # Examples
  #
  #   Given User and SuperAdmin are token authenticatable,
  #   When the following configuration is used:
  #     `config.header_names = { super_admin: { authentication_token: 'X-Admin-Auth-Token' } }`
  #   Then the token authentification handler for User watches the following headers:
  #     `X-User-Token, X-User-Email`
  #   And the token authentification handler for SuperAdmin watches the following headers:
  #     `X-Admin-Auth-Token, X-SuperAdmin-Email`
  #
  # config.header_names = { user: { authentication_token: 'X-User-Token', email: 'X-User-Email' } }

end

Using the devise way I can do

skip_before_filter :authenticate_user!, :except => [:update, :you_have_to_be_logged, :yadayada]

But if I put acts_as_token_authentication_handler_for on my base controller these "skip" operations have no effect and all my app becomes locked. How do I override these?

I am trying to override the registration controller so I can respond with JSON. The issue I am having is that authenticate_scope! is called before [:edit, :update, :destroy] and I need the users to be able to modify their profiles. Is there a good way to handle this with a simple_token_authentication method or something?

Why I set acts_as_token_authentication_handler_for User to my ApplicationController, I will have the problem is NameError - undefined methodauthenticate_user!'`. I am the reference document, but also has this problem, I don't know what is happen.

Sorry, probably this questions shouldn't be here but I couldn't find any other medium to contact Gonzalo (do you have a twitter account?).

So, the docs says:

Configure the session persistence policy after a successful sign in,

in other words, if the authentication token acts as a signin token.

If true, user is stored in the session and the authentication token and

email may be provided only once.

If false, users must provide their authentication token and email at every request.

config.sign_in_token = false

I'm going to consume my App API with an android client. How can the server know which user is authenticated on which tablet? What should I send the server after the authentication?

As a paranoid developer
In order to ensure old tokens can't be used to hijack my API users accounts
I want to be able to provide the location of a list of old tokens for each user
And I want the gem to check that list on sign in so it does not generate twice the same authentication_token for the same user

The idea of this issue takes origin in this description of a token renewal mecanism, which I consider necessary on every token authentication implementation.

Instead of using the X-User-Email header allow the developer to pass a different header name. In my case I want to use X-User-Username.

I already have some code for it but will finish it off later today. I will try post a link to my commit so you can take a look at it.

As a developer
In order to avoid having to fork the gem to set the Devise sign_in method store option to a value different from the default
I want that option to be accessible from an initializer

Devise already defines a railties dependency. The current rails dependency in this gem prevents you from installing this on rails 3.2

As a developer
In order to set the defaults I prefer
And to do it in the way I use to
I want SimpleTokenAuthentication to provide a configuration mecanisme which allow me to configure it from an initializer file
And the initializer to follow the pattern:

# config/initializers/simple_token_authentication.rb
SimpleTokenAuthentication.configure do |config|

  # Option defaults description
  config.option = value
end

Many cases it seems a password change should generate a new token.

When using this gem for a json api exclusively what is the best practice configuration?
How are controllers protected since there is no "authenticate_user" method.

My config is below, please correct me.

for this gem:

1. config.sign_in_token = false

2. acts_as_token_authentication_handler_for User, fallback_to_devise: false

In application_controller.rb, I assume this is diabling json csrf protection?
3) protect_from_forgery with: :null_session -> csrf protection
4) skip_before_action :verify_authenticity_token, if: :json_request?

In devise gem configs to disable redirects:
5) config.to_prepare do
DeviseController.respond_to :json
end
6) config.navigational_formats = ['/', :html]

My issues:

With the above configuration in an api should I be disabling csrf and devise fall_back? #49 seems to imply that the devise fallback should be disabled for api is this correct?

Also, since the fallback is disabled will I have to handle cases in which current_user is missing?

I hope this not a silly question with a simple answer. When token authentication was built into Devise it was a Devise strategy - https://github.com/plataformatec/devise/blob/v3.0/lib/devise/strategies/token_authenticatable.rb

In simple_token_authentication some patterns are kind of duplicated, for example acts_as_token_authenticatable which could be devise :token_authenticatable, ... or acts_as_token_authentication_handler_for User which duplicates before_action :authenticate_user!

I believe that making simple_token_authentication a strategy will be coherent with other authentication strategies and possibly could simplify testing.

However, current implementation of simple_token_authentication allows specifying token authentication only for selected controllers. I don't know whether it is possible with a Devise strategy (Use strategy A in controller B and strategy C in controller D).

I know that it sounds like a complete redesign of the architecture with backwards incompatible changes but maybe it's worth considering.

Hello Gonzalo,
I have to migrate an application to devise3 and I'm trying your gem according to your instructions.
I cannot sign in via API, I get a 401 despite a first signin is made, I think there is a second one that generate the issue. If what i presume is correct, any ideas to solve?

Started GET "/api/v1/posts/144015.json" for 127.0.0.1 at 2014-05-06 15:43:57 +0200
  SQL (2.0ms)  USE [DB_DEV]
Processing by Api::V1::PostsController#show as JSON
  Parameters: {"id"=>"144015"}
  User Load (5.0ms)  EXEC sp_executesql N'SELECT TOP (1) [users].* FROM [users]WHERE [users].[email] = N''[email protected]'''
  SQL (2.0ms)  BEGIN TRANSACTION
   (141.0ms)  EXEC sp_executesql N'UPDATE [users] SET [last_sign_in_at] = ''2014-04-30T15:59:28.967'', [current_sign_in_at] = ''2014-05-06T13:43:58.107'', [sign_in_count] = 261, [updated_at] = ''2014-05-06T13:43:58.124'' WHERE [users].[id]= 5; SELECT @@ROWCOUNT AS AffectedRows'
  SQL (8.0ms)  COMMIT TRANSACTION
Completed 401 Unauthorized in 262.0ms

This is what I have in my Gemfile gem 'simple_token_authentication', '~> 1.0.0.beta.5' and i get this when I use bundle install simple_token_authentication (1.0.0.pre.beta.4)

I haven't read it in depth, but what I've seen looks very nice and I belive there are very valuable things to re-use from this Resitor article about Minimal API Authentication. Do you have any suggestion about that?

Note: The original question was asked by @huttneab. As the qestion has no direct relation to the gem testing, I open this new issue in order to keep topics separate. Replies should be posted here.

Does anyone know the proper way to override the session controller to work with token authentication and respond with json, I have mine sort of working, but it's using the warden.authenticate!, which doesn't seem to work correctly.

mongoid support?

My Api is returning nil for current_user when I pass email and token through the header. My session controller sees current_user when creating and destroying a new session.

module Api
  module V1

    class UsersController < Api::V1::ApplicationController

      include Devise::Controllers::Helpers

      acts_as_token_authentication_handler_for User, fallback_to_devise: false

      def index

        render json: {
                     success: true,
                     auth_token: current_user.authentication_token,
                     email: current_user.email
                   }

      end

    end

  end
end

I had some trouble using this gem with namespaced classed.

I think the reason is because the underscore inflector is used throughout the code and converts classes like "Core::User" to 'core/user' which might be invalid syntax.

One example is line 120 of acts_as_token_authentication_handler.rb.

      def define_acts_as_token_authentication_helpers_for(entity_class)
        entity_underscored = entity_class.name.singularize.underscore

        class_eval <<-METHODS, __FILE__, __LINE__ + 1
          def authenticate_#{entity_underscored}_from_token
            authenticate_entity_from_token!(#{entity_class.name})
          end

Another example might be line 70: X-#{entity_class.name.singularize.camelize}-Token"
this would look for a token called "X-Core::User-Token" which might not be valid syntax. Not sure...

Anyway, I got it working by using the devise strategy branch and specifying the header names in devise.rb initializer.

Oh, and thanks so much for this gem!!!

I'm building a JSON API with an Ember front-end. Therefore, I want to be able to turn of CSRF validation for JSON requests, as references a number of times in previous issues. If I do that, requiring authentication tokens is the only way to secure JSON requests.

However, based on what I can see in https://github.com/gonzalo-bulnes/simple_token_authentication/blob/master/lib/simple_token_authentication/acts_as_token_authentication_handler.rb#L23-L26, this gem delegates to Devise's default authentication mechanism after doing token authentication.

Devise's default authentication makes every request fallback to cookie authentication. That means any existing users will still be using cookies until they sign out & sign back in. Also, when I disable CSRF validation on JSON requests, I'll still be vulnerable to CSRF attacks. The reason I want token authentication is so I can force clients to send identifying information with every request. Falling back to devise's authentication seems to defeat that purpose.

I can think of a few possible ways to solve this:

1. Remove the fallback entirely, but that might not work well for existing users
2. Only fallback for non-JSON requests by default (maybe with an opt-in for the previous behavior)
3. Disable fallback for all requests with opt-in to fallback on all requests

I'm thinking I might implement option 2 and send a PR. @gonzalo-bulnes any thoughts on this?

As a developer
In order to prevent dramas
And to learn about modules testing
I want the gem to contain a decent set of tests before its v1.0.0 is released

Any kind of help will be very appreciated! : )

I'm running into an issue where Login via a JSON API using Simple Token Auth works, token authentication works, but I am always getting 401 authentication issues with the logout call.

I'm working on a couple of Rspec tests to demonstrate the issue. The authentication via token works every where else (test suite and in real life). It's just logout where I constantly get a 401.

I have Devise configured to accept logout via GET (rather than DELETE). Otherwise, my issue sounds similar to this recent, unanswered thread: http://stackoverflow.com/questions/24092791/ruby-on-rails-curl-delete-token-authentication

Does this sound like a Devise issue or a Simple Token Auth issue?

Two failing test cases are below.

Any and all thoughts would be greatly appreciated!

app/controllers/api/v1/api_controller.rb

class Api::V1::ApiController < ApplicationController
  acts_as_token_authentication_handler_for User, fallback_to_devise: false
  before_action :authenticate_user!
  skip_filter :authenticate_user!, only: [:connection_test]

  respond_to :json

  protect_from_forgery with: :null_session
end

app/controllers/api/v1/sessions_controller.rb

class Api::V1::SessionsController < Devise::RegistrationsController
  prepend_before_filter :require_no_authentication, only: [:create]
  skip_filter :authenticate_entity_from_token!, only: [:create]
  skip_filter :authenticate_user!, only: [:create]
  before_action :ensure_params_exist
  skip_before_action :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,
        user_id: resource.id,
        restaurant_id: resource.restaurant.blank? ? nil : resource.restaurant.id,
        driver_id: resource.driver.blank? ? nil : resource.driver.id
      }
      return
    end
    invalid_login_attempt
  end

  def destroy
    sign_out(resource_name)
  end

  protected

  def ensure_params_exist
    return unless params[:user].blank?
    render status: 422, json: {
      success: false,
      message: 'missing user parameter'
    }
  end

  def invalid_login_attempt
    warden.custom_failure!
    render status: 401, json: {
      success: false,
      message: 'Error with your login or password'
    }
  end
end

config/routes.rb

  devise_for :users, path: '', path_names: { sign_in: 'login', sign_out: 'logout', sign_up: 'register', edit: 'account' }

  namespace :api do
    namespace :v1, constraints: { format: 'json' }, defaults: { format: :json } do
      devise_for :users, path: 'users', path_names: { sign_in: 'login', sign_out: 'logout', sign_up: 'register', edit: 'account' }
      ...
    end
  end

spec/controllers/api/v1/sessions_controller_spec.rb

require 'spec_helper'

describe Api::V1::SessionsController do
  before(:each) { @request.env["devise.mapping"] = Devise.mappings[:user] }
  ...

  describe 'GET logout' do
    context 'for drivers' do
      it 'logs out drivers' do
        request.accept = 'application/json'

        resource = create(:driver)
        @user = resource.user

        # setup the api authentication headers
        request.headers['X-User-Email'] = @user.email
        request.headers['X-User-Token'] = @user.authentication_token

        get :destroy
        expect(response.status).to eq(200)
      end
    end

    context 'for restaurants' do
      it 'logs out restaurants' do
        request.accept = 'application/json'

        resource = create(:restaurant)
        @user = resource.user

        # setup the api authentication headers
        request.headers['X-User-Email'] = @user.email
        request.headers['X-User-Token'] = @user.authentication_token

        get :destroy
        expect(response.status).to eq(200)
      end
    end
  end
end

More of a question than an issue. I noticed you posted how you would override devise session controller to handle json responses (https://gist.github.com/gonzalo-bulnes/9001010).

What is the strategy for user registration with this gem? Does it make sense to use normal devise controller? Should I just create one that creates a user and all token mechanics will work fine because of the ensure_token on user save? What do you suggest for this?

Looking at the code I noticed you use .first to check if token is available (in generate_authentication_token). Wouldn't exists? be a better fit?

def generate_authentication_token
  loop do
    token = Devise.friendly_token
    break token unless self.class.where(authentication_token: token).exists?
  end
end

How can I change the JSON response when the user logs in with the incorrect email or password? Right now the JSON response is:
{"error":"Invalid email or password."}

I need to change it so it is consistent with the rest of my API. I need it to be:

{"success":false, "info":"you need to be a paying customer", "data":{}}

Hi,

How I authenticate at cucumber using simple_token_authentication?

I'm trying use:

When I authenticate as the user "auth_token_523" with the password "random string"

hi @gonzalo-bulnes ,

i'm trying to get the gem working for the api part of my app.

using

gem 'simple_token_authentication'

i set up

class Api::V1::BaseController < ActionController::Base
    acts_as_token_authentication_handler_for User, fallback_to_devise: false
end 

and

  config.sign_in_token = false

i manage to login using request headers and i reach the controller action

i'm not using

before_filter :authenticate_user! 

but i get

undefined local variable or method `current_user'

am i missing something? do you need more info?

thank's

Despite what's said in the documentation, the ActsAsTokenAuthenticatable module is now tied to User, which means you can't make Admin or ApiUser act as token authenticatable.

There is no reason to such limitation, and token authenticatable behaviour should be applicable to any model as long as you added Devise to it.

hi @gonzalo-bulnes ,

while trying to get the gem working for the api part of my app

this is my base controller :

class Api::V1::BaseController < ActionController::Base
    acts_as_token_authentication_handler_for User, fallback_to_devise: false
    end
end

i manage to log in successfully using headers but when getting to the controller action because

before_filter :authenticate_user! 

is not defined i get the error for current user.

am i missing some declaration or a method ?

if you need more info please tell me.

thank's

Is the token expirable?

I didn't see any configuration to achieve this. Is there a way to do it with simple_token_auth?

Thanks in advance!

Kevin

User is hard-coded into the gem many times making it impossible to use with a Devise model of a different name.

I am having the strangest issue. I am only having successful authentications on GET's. I am passing the email and token via headers, not params: X-User-Email It works on GET, but not on PUT or PATCH.

When I run a debugger it goes to the authenticate_entity_from_token! method only on GET. But on a PATH or PUT I get a ActionController::InvalidAuthenticityToken
and it does not go to the authenticate_entity_from_token! method.

My routes are regular REST resources. It is a simple Rails 4 app with a single model just for testing.

It took me a while to realize this gem was at fault, but after I added it to my Rails project I could no longer access my public pages -- it was forcing me to the login page instead. The reason is ActionController::Base.send :include, SimpleTokenAuthentication::ActsAsTokenAuthenticationHandler automatically includes the before_filter :authenticate_user_from_token! macro into ActionController::Base which all controllers inherit from. Inclusion of these macros shouldn't happen until I add acts_as_token_authentication_handler to one of my controllers myself.

I opened this issue to reply to the first @halpimded comment in #14.

The test suite was failing on OSX since Mac sed requires an extension to be named for backup files, whereas it is optional for BSD sed

relevant StackOverflow question

Is there an easy way to allow a guest account?

I have a single route that I have skipped authentication on in Devise using the except: syntax in the relevant controller. But when I apply this token authentication technique in my Application Controller, that endpoint just shows the "You are being redirected" link instead of the public content. Any tips on this?

Thanks,

Walter

I saw someone already posted on trying to do this, but i've had no luck. It seems when I try to go to the users/edit page (edit registration), I get an unauthorized error, even though the token and email are passed in. Is there a way to override the registration controller without it using it's normal authenticate_scope! and using the token authentication method instead?

I know this has been discussed here and here (where I pasted a gist for my custom Sessions).

I was thinking it was all going alright, but I now realize it is not. When trying to logout with the wrong token, I get the following error:

Completed 500 Internal Server Error in 125ms

NoMethodError (undefined method `authentication_token=' for nil:NilClass):
  app/controllers/sessions_controller.rb:18:in `destroy'

I am able to create a session, the token is returned and I can logout successfully when the token is correct. When I pass the wrong token, however, I get that error.

Shouldn't I get a Completed 401 Unauthorized in 5ms just like I do when I try checking a dummy page I created which inherits from ApiController (which uses the same acts_as_token_authentication_handler_for User instruction)?

Thanks,
Daniel

My User class needs to be looked up by login, which for me is email or username. (And my implementation essentially follows this.)

Is there a simple way to accomplish this?

Judging by the devise entity lookup I found, thing's are presently hardcoded to lookup by email. If this is something I could submit a PR for, I'd be happy to contribute.

Thanks in advance,
Brad

I have a use case where I have two models: a Devise-CAS-authenticated User and a token-authenticated Partner. The user should be able to crud partners, while a partner is only allowed to show his page and post to a custom controller action.

I was thinking something along the lines of:

class PartnersController < ApplicationController

    acts_as_token_authentication_handler_for Partner
    before_action :authenticate_partner!, only: [:show, :confirm]
    before_action :authenticate_user!

    [controller actions]
end

The problem here however is that when I navigate as an authenticated User to the index method, my access gets denied. This is because (correct me if I'm wrong) the acts_as_token_authentication_handler already includes the before_action authenticate_partner! as a fallback if the token authentication fails, causing the authentication to fail, and throwing the 403 error.

Is there a way around this or is it possible to restrict the acts_as_token_authentication_handler to certain controller actions?

Thanks in advance.

I've opened this issue to follow the discussion started by @dmdeller and @austinpray (original post) while keeping it separated from the #26 issue main topic.

As a developer
Given that I've decided the next release will be v1.1.0, a minor version change
In order to be compatible with the the semantic versioning principles
I want the API changes to ensure backward compatibility with v1.0.0.

I forgot that when I merged #28 : (

I'm trying to add a secure API for my rails app, which it uses Devise for the user authentication and a mobile app will be able to use this API.

I'm following this tutorial: http://lucatironi.github.io/tutorial/2012/10/15/ruby_rails_android_app_authentication_devise_tutorial_part_one/ but it uses the deprecated authentication token.

My question is if I install this gem, and configure the models and controllers, I will be able to use the old methods like verify_authenticity_token?

Do you know another way or tutorial in which explain how to authenticated in a mobile app through Devise rails app?

I'm not sure if this goes here. I have forked the repository, and I am trying to modify it.

When I try to run the test suite, I'm getting this error. Devise is in my gem list.

uninitialized constant Devise (NameError)
/simple_token_authentication/spec/dummy/config/initializers/devise.rb:3:in `<top (required)>'

Steps I took
I forked the repository
Cloned it locally
I'm using rvm with ruby 2.1.2 and created a new gem set
I ran bundle
I ran rake

It seems like this gem stores the authentication tokens in plain text. Doesn't this pose a security risk? If anyone ever got read access to the database, they could have everyone's token. Was there a reason that tokens are not encrypted?

I was alerted to this issue here:
http://stackoverflow.com/questions/18605294/is-devises-token-authenticatable-secure

The rails-api gem uses ActionController::API instead of ActionController::Base for its controllers. Maybe replacing this line for

ActionController::API.send :include, SimpleTokenAuthentication::ActsAsTokenAuthenticationHandler 

should work