Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Introduction

In the Basic Service example, we learned to perform a heartbeat check on a service to monitor its health.

Moreover, sample tests to expose the basic functionalities of a SOAJS service, and those of the IMFV.

In this section, one of the APIs from the Basic Service example was secured with oAuth. When securing a service with oAuth, the service becomes accessible only to users with valid oAuth credentials.

Every request made to the service is first validated by the SOAJS oAuth Service before being forwarded to the service.

Code Walkthrough

This page shows you how to interact with example02 service after you install it and run it.

The code walkthrough is located in a sub page and explained in depth. Click here to read the explanation.

Service Exploration

Run the Service

# go to correct directory
cd /opt/soajs/node_modules/soajs.examples/example02/

# export necessary environment variables
export SOAJS_PROFILE=/opt/soajs/node_modules/soajs.utilities/data/getStarted/profile.js
export SOAJS_ENV=test
export SOAJS_SRVIP=127.0.0.1

# start service
node .

Since this example makes use of the oAuth service, let's go ahead and turn that service on as well.

In a separate terminal window, enter the following:

# go to directory and install oauth
cd /opt/soajs/node_modules/
npm install soajs.oauth

# go to oauth directory
cd /opt/soajs/node_modules/soajs.oauth

# export necessary environment variables
export SOAJS_PROFILE=/opt/soajs/node_modules/soajs.utilities/data/getStarted/profile.js
export SOAJS_ENV=test
export SOAJS_SRVIP=127.0.0.1

# start service
node .


The oAuth service listens on port 4002, and its maintenance port is 5002.
Let's send a heartbeat request to verify that oAuth is running healthily:

curl -X GET "http://127.0.0.1:5002/heartbeat"

The response below indicates that the oAuth service is running error free.

{"result":true,"ts":1425131003103,"service": {"service":"oauth","type":"rest","route":"/heartbeat"}}

Another heartbeat request is sent to the example02 service whose maintenance port is 5011.

curl -X GET "http://127.0.0.1:5011/heartbeat"

The response below indicates that the service is running without any errors.

{"result":true,"ts":1425131238011,"service": {"service":"example02","type":"rest","route":"/heartbeat"}}

Using the Service APIs

In the Basic Service example, the "testGet" API was not designed to be secured with oAuth. In this example we added this security option to it.

The following example is a request to the testGet API, without providing the required authentication credentials.

# go to controller directory 
cd /opt/soajs/node_modules/soajs.controller

# export necessary environment variables 
export SOAJS_PROFILE=/opt/soajs/node_modules/soajs.utilities/data/getStarted/profile.js 
export SOAJS_ENV=test 
export SOAJS_SRVIP=127.0.0.1 

# start service 
node .

# hit the API
curl -X GET "http://127.0.0.1:4000/example02/buildName?firstName=John&lastName=Smith"

As expected, the API replied with an error stating that The access token was not found. Thus, the user was not permitted to access the services of this API.

{result: false, errors: {codes: [ 400 ],details: [ { code: 400, message: "The access token was not found"}]}}

Login to oAuth 

The user must login to oAuth and get an access token.

The code block below represents a request to the oAuth/token API.

The header contains the tenant key. More details regarding the tenant key can be found in the Multitenancy section in the documentation.

The Authorization in the header is used by oAuth to validate both posted body and is explained in detail in oAuth section under documentation.

The body, on the other hand, accepts three input parameters: username, password, grant_type.

curl -X POST -H "Authorization: Basic MTBkMmNiNWZjMDRjZTUxZTA2MDAwMDAxOnNoaGggdGhpcyBpcyBhIHNlY3JldA==" -H "key:aa39b5490c4a4ed0e56d7ec1232a428f771e8bb83cfcee16de14f735d0f5da587d5968ec4f785e38570902fd24e0b522b46cb171872d1ea038e88328e7d973ff47d9392f72b2d49566209eb88eb60aed8534a965cf30072c39565bd8d72f68ac" "http://127.0.0.1:4000/oauth/token" -d 'username=oauthuser&password=oauthpassword&grant_type=password'

The corresponding response contains the corresponding access_token, which expires in one hour (in this example), and refresh_token, that is used once the access_token expires.

{"token_type":"bearer","access_token":"30f3a13fcdb60cde1cdf576634cbb7777df31177","expires_in":3600,"refresh_token":"6ea967dfe6c005d86b6fb0b0331ed52b89a1cee7"}

TestGet with a valid oAuth access token

What follows is a new request to the testGet API. However, the request in this example contains the valid access_token obtained above. As can be seen in the code block below, the access_token is appended to the request.

curl -X GET "http://127.0.0.1:4000/example02/buildName?firstName=John&lastName=Smith&access_token=30f3a13fcdb60cde1cdf576634cbb7777df31177"

As a result, after validating the legitimacy of the access_token, the API responds with a successful response to the user.

{"result":true,"data":{"fullName":"John Smith"}}
  • No labels