Kinto-discovery-lib API

We created a library kinto-discovery-lib, that has been published on npm (https://www.npmjs.com/package/kinto-discovery). In this, we have implemented all the usecases in lib/index.js and the testing of each usecase is done in tests/discovery_test.js .

The library has two main functions,

a) to let the user to register the user storage in the central repository.

b) to enable the user to retrieve the user storage url from the central repository.

The registerUserURL:

This function takes in the user ID, the url of the central repository of an application, the authorization headers, the url of the user’s storage and the local storage as parameters.

In this function, the main aim is to push the url of the user’s storage in the central repository.

– The function hashes the user ID. This hashed ID is the record ID (as in the collection, records stored need to be referenced by a unique ID).

– We then check if the headers contain Authorization headers. If not, an error is thrown.

– Now, a push is done on the central repository, as we have defined the permission to let any user write to the repository, however, a user can access only the record that the user has written.

– If the record is successfully added to the central repository, the user’s storage url is stored in local host, with key containing ‘kinto:server-url:’ + userID; that maps to the user’s storage.

– If any errors occur, for example: 404, or >=500, an appropriate error is thrown.

The retrieveUserURL:

This function takes in the user ID, the url of the central repository of an application, the authorization headers, url of default storage server and the local storage as parameters.

In this function, the main aim is to retrieve the user’s storage from the central repository.

– The function hashes the user ID. This hashed ID is the record ID (as in the collection, records stored need to be referenced by a unique ID).

– We then check if the headers contain Authorization headers. If not, an error is thrown.

– The default server is the server used in case the user’s storage is not found in the central repository. If this field is null, an error is thrown: defaultServer should be defined.

– The key for the user is obtained as ‘kinto:server-url:’ + userID. If the user’s storage is found in the localStorage, via the key, then this url is used, else

– A fetch request is done on the central repository. We have set the permission such that a user can read only the record that the user has written to the central repository.

– If the record is successfully retrieved from the central repository, the user’s storage url is stored in local host, with key containing ‘kinto:server-url:’ + userID; that maps to the user’s storage.

– If any errors occur, for example: 404, 403,401 or >=500, an appropriate error is thrown.

Tests:

The following tests have been written for each usecase in the given functions:

getUserIDHash(userid):

    

This function will be used by registerUserStorageURL and retrieveUserStorage.


Success cases: 

– When I pass the same user id to the function, I expect to always have the same hash back.

– When I pass different user ids to the function, I expect to have a different hash back


registerUserURL:


This function takes:

    – the userid,

    – the central repository url,

    – the authentication headers,

    – the user kinto server storage URL

    

It returns the storage url.

It can throw in case of server error.

It can throw in case of function misuse.


Success cases

– We set the storage URL into the central repository return it back.

– When I pass a storage_url, it is cached in the local storage for later use.


Failures cases

– When the authentication headers are empty, the promise should be rejected with an appropriate error message

– When the headers are invalid, the promise should be rejected with an appropriate message

   – The user doesn’t have the permission to write in the central repository (the central repository is not correctly configured)   [?]

– When the server is not available, I expect the promise to be rejected


retrieveUserURL:


This function takes:

    – the userid,

    – the central repository url,

    – the authentication headers,

    – the default kinto server to use


It returns the storage URL to use (user one or default one)

It can throw in case of server error.

It can throw in case of function misuse

    

Success cases

– When the storage URL is set it should be use instead of the default one.

– When the storage URL is set it should cached in the localStorage and reuse the second time.

– When the storage URL is not set, it should use the default one.

– When I come for the second time, the storage_url is taken from the local cache

– When a storage_url is available in local cache, no query is sent to the server.(fetch not called)


  • Failures cases

– When the server returns a 403 (no storage url is found for this user) the default server should be returned.

– When an empty default server is passed, the promise should be rejected with an appropriate message  (does not have a promise, returning before fetch as it gave an error on doing a fetch) 

– When the server is not available, The promise should be rejected with an appropriate error message

– When the headers are invalid, the promise should be rejected with an appropriate message 


.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s