-
Notifications
You must be signed in to change notification settings - Fork 0
Node.js Server
The API for this project allows an admin to login to the streaming app and create, edit and delete a streaming channel. Admin can also start and stop broadcasting on an existing channel. Another role available is the user role. A user can login into the viewing app using a two factor authentication. Upon login, a user can view their channels, search for them and mark their favorites. They can also start and stop viewing the channel broadcasts. The API uses MongoDB Atlas cloud database and Digital Ocean Ubuntu droplet for hosting our API.
Before any or some of this functionality is provided, this API will execute some custom middleware as discussed below:
1. Connecting to Database:
Before hitting any of the endpoints, our API needs to connect to our MongoDB Atlas database to retrieve/save/update data. This middleware will establish this connection with the database using a database URL before processing any request. If the connection is established, the request will forward to the intended endpoint or the next middleware (as suited for the specific case), otherwise an error response will be returned to the users specifying that the database connection cannot be established.
2. Authenticating user:
This middleware will execute only for users who are logged into the system using the login functionality. Whenever a user tries to access any of the endpoints, a JWT bearer token needs to be specified in the Authorization header in the request along with other endpoint specific data. This middleware will check for this token. If the token is not found in the request or has elapsed the duration of 1 hour/24 hours (token time to live depends upon mechanism used for login) since its issuance then an error response will be sent to the users with an appropriate response, otherwise on successful validation of the token, the API will then proceed to fulfill the request using the appropriate endpoint or go on to the next middleware as suited for the specific case. The JWT is created and validated in the API using jsonwebtoken library of node. There are two authorized roles in this system: admin and user. The admin token has 1 day time to live and the user token has
3. Authorizing user: This middleware will execute only for endpoints beginning with '/api/v1/user' pattern. It will make sure that users trying to use the endpoints with the mentioned pattern as essentially users by role, by checking for the user ID in the users collection.
3. Authorizing admin: This middleware will execute only for endpoints beginning with '/api/v1/admin' pattern. It will make sure that users trying to use the endpoints with the mentioned pattern as essentially admins by role, by checking for the admin ID in the channels collection.
Let's now discuss the API end points in details:
| No. | Verb | Endpoint |
|---|---|---|
| 1 | GET | 206.81.0.65:3000/api/v1/login/admins |
Header: {Authorization:Basic <base64encoded_username:password>} This endpoint allows an admin to login to the streaming app using a pre-issued username and password. Upon successful login, the admin info along with channel info for the admin (if present) will be returned along with a token having a time to live of 24 hours. The admin password is hashed and salted, hence we use the bcrypt.js library to verify the provided password with the saved one.
| No. | Verb | Endpoint |
|---|---|---|
| 2 | GET | 206.81.0.65:3000/api/v1/admin/profile |
Header:
{Authorization:Bearer <token>}
This endpoint will allow an admin to fetch their own profile information, based on which token is passed to it.
| No. | Verb | Endpoint |
|---|---|---|
| 3 | POST | 206.81.0.65:3000/api/v1/admin/channels |
Header:
{Authorization:Bearer <token>}
Body:
{
"channelName":"new channel",
"channelId":"789011",
"users":[
"aditi@gmail.com",
"anirban@gmail.com"
]
}
The following data needs to be provided to create an admin channel. At a time, an admin can own only one channel. Hence this endpoint will allow them to create a channel only if they do not have an existing channel. For a channel, an admin can add only 1 to 4 existing users. Duplicate users or non-existant users in the users list will not be tolerated by this endpoint. This endpoint will create the channel only in our application database and not on liveSwitch.
| No. | Verb | Endpoint |
|---|---|---|
| 4 | PUT | 206.81.0.65:3000/api/v1/admin/channels |
Header:
{Authorization:Bearer <token>}
Body:
{
"channelName":"new channel",
"users":[
"aditi@gmail.com",
"anirban@gmail.com"
]
}
The admin is allowed to change the users and channel name of their existing channel using this endpoint. For a channel, an admin can add only 1 to 4 existing users. Duplicate users or non-existant users in the users list will not be tolerated by this endpoint
| No. | Verb | Endpoint |
|---|---|---|
| 5 | DELETE | 206.81.0.65:3000/api/v1/admin/channels |
Header:
{Authorization:Bearer <token>}
This endpoint will allow an admin to delete the channel they own (if they do own a channel).
| No. | Verb | Endpoint |
|---|---|---|
| 6 | GET | 206.81.0.65:3000/api/v1/admin/channels |
Header:
{Authorization:Bearer <token>}
This endpoint fetches the channel created by the logged in admin, if they own one.
| No. | Verb | Endpoint |
|---|---|---|
| 7 | POST | 206.81.0.65:3000/api/v1/admin/users |
Header:
{Authorization:Bearer <token>}
Body:
{
"name":"anirban acharya",
"age":"25",
"email":"anirban@gmail.com",
"password":"user123"
}
An admin is allowed to create new users if they wish. The following data needs to be provided to create a new user. In order for a user to be registered, they need to be more than 10 years of age, need a unique email id and a password having length of 6 to 20 characters. This registered user can now be used by any admin to add as an authorized user to their channel. While saving the user to the database, the user password will be hashed and salted for security, using the bcrypt.js library.
| No. | Verb | Endpoint |
|---|---|---|
| 8 | PUT | 206.81.0.65:3000/api/v1/admin/broadcasting |
Header:
{Authorization:Bearer <token>}
Body:
{
"isBroadcasting":true
}
This endpoint allows an admin to change a channel's broadcasting status or true or false. This comes into play if an admin attempts to broadcasts video content from two separate devices over the same channel. This API will restrict them from doing so.
| No. | Verb | Endpoint |
|---|---|---|
| 9 | POST | 206.81.0.65:3000/api/v1/admin/verifyFace |
Header:
{Authorization:Bearer <token>}
Body:
{
"url":<image_url>
}
This endpoint will be called when the streaming app is trying to create a new user. Along with other information, the admin also needs to set an image while creating the user. This is the image which will then be used to face verify the user during login into the viewing app. Hence before the streaming app saves this image, we make sure that the clicked photo has only one face present in it using this API. This API uses the Microsoft Face DETECT API to confirm the number of valid faces in the image. The Microsoft Face DETECT API returns a faceId and a set of attributes for every face present in the image. If the number of faces fetched from this api less than or greater than 1, then the image is not treated as a valid image and the user will be asked to user another image for the purpose.
| No. | Verb | Endpoint |
|---|---|---|
| 10 | GET | 206.81.0.65:3000/api/v1/admin/verifyUser?email=<email_id> |
Header:
{Authorization:Bearer <token>}
This endpoint helps an admin identify if an email id belongs to a valid user in the database or not.
| No. | Verb | Endpoint |
|---|---|---|
| 11 | GET | 206.81.0.65:3000/api/v1/login/users |
Header:
{Authorization:Basic <base64encoded_email:password>}
This endpoint will allow a user to take the first step towards login to the viewing application using a registered email id and password. If the email id and password match to an existing user, a token having a time to live of 5 minutes will be issued to the user, which will be used to proceed to the next step of user verification. The user password is hashed and salted, hence we use the bcrypt.js library to verify the provided password with the saved one.
| No. | Verb | Endpoint |
|---|---|---|
| 12 | POST | 2206.81.0.65:3000/api/v1/user/verifyFace |
Header:
{Authorization:Bearer <token>}
Body:
{
"url1_token":"77c1ddf1-136c-40d9-9ce1-9bd1410d1bf7",
"url2_token":"77c1ddf1-136c-40d9-9ce1-9bd1410d1bf7"
}
The next step of user verification is face verification. Two image url tokens (firebase storage) are required for endpoint. Using these tokens and the user id, a firebase image URL will be generated by the endpoint. This endpoint will make sure that the faces of the user trying to login and the registered user are the same. If they are the same, a token of 1 hour will be issued to the user for further user. In order to verify to faces, we use the following two Microsoft API:
- Face Detect API
- Face Verify API Face Detect API, detects the faces from the two provided user images generates a faceId for each of them. If invalid an invalid and or less than or grater than 1 face in either image is encountered, an appropriate error is sent in the response. Else we proceed to verify the two faces detected. The Face Verify API now takes the two faceIds generated by the Face Detect API and compares them for similarity. It returns a boolean "isIdentical" as the response. If the boolean is false, the faces don't match, else they match. Along with the boolean "isIdentical", a % confidence of that decision is also returned. We use this information to verify a face to be similar in our application.
| No. | Verb | Endpoint |
|---|---|---|
| 13 | GET | 206.81.0.65:3000/api/v1/user/profile |
Header:
{Authorization:Bearer <token>}
This endpoint allows a user to fetch their profile information.
| No. | Verb | Endpoint |
|---|---|---|
| 14 | GET | 206.81.0.65:3000/api/v1/user/channels |
Header:
{Authorization:Bearer <token>}
This endpoint allows a user to fetch the list of channels they are authorized to use. It also allows a user to specify a query param called "channelName". This query param when specified will filter the results by channel name.
| No. | Verb | Endpoint |
|---|---|---|
| 15 | GET | 206.81.0.65:3000/api/v1/appConfig |
Header:
{apiKey:<key>}
This endpoint connects to live switch to fetch all the keys required to access liveSwitch features. In order to do so, a liveSwitch API key needs to be passed into the arguments. Using this key, we will hit a liveSwitch endpoint to get the application config and we will then return the same in our API response.
We have used MongoDB database for our application. The database resides on an Atlas cloud cluster.
1. The database has a users collection which will store the following fields when a user is created.
- _id : Unique id assigned to the user
- name : Name of the created user
- age : Age of the user (greater than 10)
- email : Unique email ID of the user
- password : Hashed and salted password of the user.
2. The database has a channels collection which will store the following fields when a channel is created. Since each admin can create only one channel at a time, the admin and channel info are saved together here.
- _id : Unique id assigned to the admin
- username : Unique username of the admin
- password : Hashed and salted password of admin
- channelId : Id of channel created by admin
- channelName : Name of channel created by admin
- users : Arrays of user emails ids. These are users who are authorized to view the channel broadcast
- isBroadcasting : Boolean variable which specifies if the admin in currently broadcasting on the channel
3. The user images are stored using Firebase Storage. The images are fetched from firebase to verify/validate them in the APIs.


