(This description will assume a BASE_URL value which can be any http accessible url available from end user's devices)

The process has two steps Authenticate and Authorize.

Configuration Screen


Authenticate
The process operates on two pieces of data provided by the user their username (email) and password.

First a auth token is calculated by:
authToken = BaseEncoding.base64().encode((username + ":" + password).getBytes()

We construct a url for subscriber info as such:
BASE_URL/api/svcs/subscribers/$(username)

where $(username) is replaced with the specified users name

The auth token is attached to the http requests per normal Basic authentication using the "Authorization" header and the value "Basic $(auth_token)"

The response to this request should be HTTP code 200 with subscriber information formatted as json.  The format is:

{  "iD": "410413"  "firstName": "VENDOR"  "lastName": "VENDOR"  "userName": "vendors@test.com"  "email": "vendors@test.com"  "address": "5300 ABC DR"  "city": "MSP"  "state": "MN"  "zipCode": "55901"  } 

If the user is not authenticated the response, no response body is necessary and the response code should be 400.

The next step assumes a successful authentication.

Authorize
This process validates a user has access to a specific subscription.

We leverage the cached $(auth_code) stored during the Authentication process.  The HTTP call is constructed as follows:
BASE_URL/api/svcs/subscribers/$(username)/products

If there is an error, this HTTP call should return > 400

Otherwise, this call should return a list of products the user has access to:

  [     {      "userName":"vendors@test.com",      "iD":"3",      "productCode":"002",      "expirationTime":"9999-12-31T23:59:59",      "circulationDetails":{"SUB_ACTIVE":"True","PUBLICATION":"002","PUBLICATION_SUBSCRIPTION":"200","PLAN":"DigitalD"}     }    ] 

The set of specified productCodes is compared to the list of valid product codes specified in the publisher configuration (see image above).  All product codes specified in the configuration are considered "valid" and the user's list of products requires only one "match" to the valid product codes.

Note, that we have our own pay meter implementation and we track article visits, credential expiration and article meter configuration within our publishing platform.

Did this answer your question?