apikey, user id and password in js file

[bhupesh]

I am new to everlive. I am trying to create a website that can access the same backend service that my mobile app uses.
I have a question o nthe below javascript snipet I founf in a telerik blog.


var el = new Everlive('YOUR_API_KEY');
Everlive.$.Users.login('jsmith', // username
'password') // password
.then(function (data) { // success callback, this returns the token that we can store to avoid re-authenticating this user!
alert(JSON.stringify(data));
},
function(error) { // error callback
alert(JSON.stringify(error));
});


If I put the above in a js, upload it on to my server, the js will contain clear database password and api key. Is it not a security concern because javascript can be accessed from client machine?

[Anton Dobrev]

Hi Bhupesh,

As to your questions.

1. API key

The API key for a backend application is required for personalizing all client-side requests to the Backend Services' API for a given application. It is intended to be used in the client app and is included in all API requests. All endpoints to a backend data store are constructed with the API key as one of the segments. Nevertheless, anyone knowing your API key will not be authorized to read data from the app's backend if the permissions for the content types are properly set up.

2. User credentials

The described code snippet is used to login a user in your app with the provided username and password which are subsequently verified by the server and in case of successful authentication are exchanged for an access token. It is also intended to reside in the client app.

You can store the token / credentials for further use in the local storage or a cookie, in the case of web apps, on the user's machine but a good practice is to ask for the user's permission to store the credentials.

3. Security

What you need to ensure further is:

• The MasterKey for a project is never exposed client-side and to any third party. In general, operations that include master key should be done only by you or performed in the Cloud Code layer for enforcing additional security or for performing some business logic operations.
• The content types in the backend project have the appropriate permissions set up. Content types in Backend Services are created with default permissions and developers need always to verify that the type of the permissions matches their scenario.

Thus, you can be sure that the authentication for a request will be based on the currently logged user's permissions (role-based security), and on the permissions for a content type (type-level permissions). In addition, you can specify item-level permissions for a more refined access to the data.

4. Example

For example, the registered users authenticate with the following header {"Authorization: Bearer <access_token>"} when logged in the app. All requests on their behalf will be handled according to the permissions set up for a content type for the role of this user. How to obtain an access token is described in this documentation article. The JavaScript SDK stores the token for the user when a user authenticates successfully and authenticates each subsequent requests with it. 

Continuing on this, you can experiment with the permissions for a certain content type and explore the behavior of the quoted endpoint. For example, you can specify a predefined security policy or pick up Role-Based from the drop down menu and arrange a really flexible security strategy.

Moreover, you can create new roles and assign users in roles, so that you have a solid control over the data access.

Here is the starting point in regard to security from our documentation: Features > Security > Introduction.

Please, let us know if you have further questions, we will be happy to help.

Regards,
Anton Dobrev
Telerik