ArcadeX v1.2.3

Introduction

If you've recently created an API you may have felt frustrated at the removal of Devise's token authenticatable module. ArcadeX fills the void with a set of functions that act on a token class to provide authentication to an API. It builds onto the Devise token gist by not only creating the token but also giving the option to allow for tokens to expire and contain the current ip address of the token's origin.

Enjoy!

New Additions

I generalized the token to allow for a custom header. When using get_instance or authenticate_owner_with_index you will need to pass in the header that contains the auth_token. In addition to a custom header, for additional security the owner of the token that is found can be double authenticated with an indexed attribute. authenticate_owner_with_index will take the attribute as a strign, find an object with the string and compare the two. The new flexibility of Arcadex allows for it's use in authenticating users or even application clients of the api. The token can also have a limited number of uses if desired.

Installation

	gem 'arcadex'

And because this is an engine with db tables, you need to copy over the migrations

	rake arcadex:install:migrations

Now migrate your default database. (Repeat for test and production)

	rake db:migrate

Examples

Put this in your user class

	has_one :token, :as => :imageable, :class_name => "::Arcadex::Token"
	or
	has_many :tokens, :as => :imageable, :class_name => "::Arcadex::Token"

And in a hook, you want to create one when a user is created

	after_create :create_token

	def create_token
		self.tokens.create! #use for has_many association with tokens
		or
		self.token.create! #use for has_one association with token
	end

This token should be handed out when a user is created (registers) or signs up and destroyed when the user logs out.

In your application controller we want to check to make sure the token is valid.

	before_action :authenticate_user

	#["current_owner","current_token"]
	#The second to last argument is if you included an index attribute in the params/headers. It will compare it with the owner of the token and if they dont match the return value will be nil. True just says the value in the header or params should be downcased.
	def authenticate_user
	  @instance_hash = ::Arcadex::Authentication.authenticate_owner_with_index(params,request,"Auth-Token","Email","email",true)
	  if @instance_hash.nil?
	    #There is an error
	  end
	end

	#"Auth-Token" is the header or params Arcadex will look for to grab the token
	#"Email" is the header or params Arcadex will look for to grab the indexed attribute value
	#"email" is the indexed attribute key.
	#If the owner found from "Auth-Token" does not match the object found from in the indexed attribute, nil will be returned.

	#If you don't need the indexed attribute, get_instance can just be used.
	def authenticate_user
		@instance_hash = ::Arcadex::Authentication.get_instance(params,request,"Auth-Token")
	  if @instance_hash.nil?
	    #There is an error
	  end
	end

Since you set the header to search for, multiple tokens can be sent from the front end. This makes it flexible enough for multiple layers of authentication e.g. user and application authentication. Just use get_instance as many times as you need.

The hash returned will have indexes at "current_owner" and "current_token" and it will be available to all of your controllers. Remember to skip this authentication for registrations and signing in!

If you wish to opt for tracking and token expiration, in the register or login controller, after creating a token, pass it into this function. The first argument is the token, the second is when to expire the token in minutes and request is the request hash available to all controllers. The last parameter is how many times the token can be used. Set this to nil to ignore this functionality. The same goes for the expiration minutes. If any of these two are nil, it will be ignored.

	::Arcadex::Create.set_token(token,360,request,nil)

Arcadex will first check the params for the value of the token and then the header. If you opt for param token passing and header token passing, make sure to choose a key value that is acceptable to url passing.

For example, Auth_Token: token and Email: email If you opt for get or post params Auth_Token=TOKEN&Email=EMAIL If you choose to do both, the header will have preference

There are even more methods that are available, simply check the lib folder. The methods provided make it easy for you to implement your own token or extend this one.

Remember to use https when using token authentication!

Author

Created by Cleophus Robinson (CleoR41@gmail.com)