Our job is to remind us that there are more contexts than the one that we’re in — the one that we think is reality.
― Alan Kay
Software Development and Data Consultant
Our job is to remind us that there are more contexts than the one that we’re in — the one that we think is reality.
― Alan Kay
AngularJS is an awesome javascript framework. With it’s $resource service it is super fast and easy to connect your javascript client to a RESTful API. It comes with some good defaults to create a CRUD interface.
However if you are using an API, which needs authentication via an auth token, you might run into issues: The resource factory creates a singleton. If you do not already have an auth token when the factory is called, or if the auth token changes afterwards, you cannot put the auth token as a default request parameter in the factory.
This article shows, how to solve this. First we define our resource, consuming a RESTful API, without using an authentication. Afterwards we create a wrapper to send the auth token with every request. This allows consumption of an API with an exchangeable auth token.
Here is a simple example of how to create a resource in your client, fed by a RESTful backend on your localhost:
angular.module('MyApp.services', ['ngResource'])
.factory('Todo', ['$resource',
function($resource) {
var resource =
$resource('http://localhost:port/todos/:id', {
port:":3001",
id:'@id'
}, {
update: {method: 'PUT'}
});
return resource;
}])
We are creating a module which depends on ngResource, which provides the $resource service. We build a factory called Todo using the $resource service.
Inside the factory we create a resource object by passing an URL and a port to the $resource constructor. Have a look at the URL string: :port and :id are being replaced by the parameters defined in the object literal right after the URL string itself.
Setting a port is not as straight forward, as it could be: In this example we are setting it to 3001. Right now you cannot put it into the URL directly, as AngularJS would interpret :3001 in the URL as a placeholder with the name 3001. So we put the placeholder :port in the URL and replace it with :3001 via the parameter object literal.
Now have a look at the :id placeholder: It’s being replaced with @id. With the @ in front, AngularJS takes the attribute with that name from the current resource when doing a request. This is very handy, when sending non-GET request. Here is a simple example: When sending an update REST action for an resource item with id=123 the URL will look like this: http://localhost:3001/todos/123.
There is one last thing in the example: We define an update action for our resource. $resource defines some default actions:
{ 'get': {method:'GET'},
'save': {method:'POST'},
'query': {method:'GET', isArray:true},
'remove': {method:'DELETE'},
'delete': {method:'DELETE'} };
I have no idea, why an update action is missing. I think it would be reasonable to add this to the AngularJS default actions. So, as the update action is missing, we define it ourselves. We just have to provide the HTTP method for it, which is PUT.
As you can see, connecting to a REST API is pretty straight forward.
To send the auth token with every request we are going to wrap the resource actions in a function which appends the auth token. So first of all we create a new service to deal with all the token related stuff:
.factory('TokenHandler', function() {
var tokenHandler = {};
var token = "none";
tokenHandler.set = function( newToken ) {
token = newToken;
};
tokenHandler.get = function() {
return token;
};
As you can see, we create a service called TokenHandler which stores the token itself and provides getter and setter methods.
Now, let’s have a look at the actual action wrapping:
// wraps given actions of a resource to send auth token
// with every request
tokenHandler.wrapActions = function( resource, actions ) {
// copy original resource
var wrappedResource = resource;
// loop through actions and actually wrap them
for (var i=0; i < actions.length; i++) {
tokenWrapper( wrappedResource, actions[i] );
};
// return modified copy of resource
return wrappedResource;
};
The method wrapAction takes a resource and an array with strings identifying the actions to be wrapped as parameters. A copy of the resource is created, modified and returned. We don’t want to change the original resource to prevent any side effects (‘Don’t change parameters inside a function’).
We loop through the actions array, calling the method tokenWrapper for every single action. So finally let us have a look what happens there:
// wraps resource action to send request with auth token
var tokenWrapper = function( resource, action ) {
// copy original action
resource['_' + action] = resource[action];
// create new action wrapping the original
// and sending token
resource[action] = function( data, success, error){
return resource['_' + action](
// call action with provided data and
// appended access_token
angular.extend({}, data || {},
{access_token: tokenHandler.get()}),
success,
error
);
};
};
return tokenHandler;
});
In a first step we copy the original action and store it with a new name. We prepend an underscore and save it into the resource. So the action query for example is now also available as _query.
Afterwards we overwrite the original action with our wrapper function. Parameters of the wrapper are identical with the normal actions: The resource data data and callback functions success and error.
The wrapper calls the renamed original action methods (_query for example) and returns the result. But checkout the first parameter we pass to the original action: We use the data parameter and append the access_token as an object literal to that. This way, the auth_token is send to the API as a parameter called access_token!
Of course we have to actually use our new action wrapper in the resource we defined in the first section. So here is how to use it:
.factory('Todo', ['$resource', 'TokenHandler', function($resource, tokenHandler) {
var resource = $resource('http://localhost:port/todos/:id', {
port:":3001",
id:'@id'
}, {
update: {method: 'PUT'}
});
resource = tokenHandler.wrapActions( resource,
["query", "update", "save"] );
return resource;
}])
The TokenHandler has to be added as a dependency and is passed as a parameter to the constructor method. No changes to the definition of resource are necessary. But before returning resource we overwrite with the result form wrapActions method of the tokenHandler. We pass the original resource and an array with string identifying the actions we want to wrap.
As you can see we can easily overwrite the default actions which are created by $resource implicitly. You can use the overwritten actions the same way you would use the defaults:
// get all todos
var todos = Todo.query();
// save a todo
todo[0].text = "New Text";
todo[0].$save();
You can get the full code of the TokenHandler service here. This approach is based on an idea by Andy Joslin on a stackoverflow question. Thanks, Andy!
[…] similar to the approach described in this blog post, originally inspired by this other Stackoverflow question. But I find it slightly intrusive, so […]
nuruddinBadawi says
February 11, 2016 at 09:11headers did not put it correctly in headers request
http://s17.postimg.org/8ms0hp3yn/Screen_Shot_2016_02_11_at_11_05_59_AM.png
Mark says
March 15, 2016 at 10:34I can’t see how this is secure? Surely an end user can see your access token in the TokenHandler service and then start sending requests to the API as you and ultimately could do malicious things? I’m trying to solve the problem now of sending auth tokens with REST calls but everything I have come across will be displayed to the end user in the JS files.
Mark says
March 28, 2016 at 22:15But the API token is in plain view in the JS file? So someone else could spam the API using your token?
DJavier says
May 3, 2016 at 15:15I really like this approach, i found this from SO, but unfortunately it doesn’t work for setting the token as a Header a not through QueryString or Payload.
I think the most common scenario is to send the authorization via a header, this would be a good plus for this post.