Youtube video 🎥💥 : https://youtu.be/tztfJ2cpj5Y
- Product service to search (Full text), filter and perform all crud operations.
- Shopping cart management.
- Dummy credit card payment gateway service.
- Dummy mobile payment gateway service using Twilio.
- Place orders with multiple products.
- Track orders.
- Using WSO2 EI (Enterprise Integration – ESB) to integrate services at the backend and expose a common web API.
- Route the payment to either the banking payment gateway or the mobile operator, based on some parameter of the payment request message.
- Frontend of Delivery service.
2. Nethmi Divya https://github.com/NethmiDivyaT/Backend-item
- Seller service where sellers can add/update/delete items.
3. Harini https://github.com/Rane1998/ds_auth
- JWT authentication service to perform role based authentication.
- Delivery service to deliver orders.
- Node, Express, JWT, Passport.
- React and Redux.
- Mongo database.
- Twilio to send SMS.
- Node mail - Gmail SMTP to send emails.
- WSO2 Enterprise Integrator.
Json web token based authentication mechanism is used to verify user identity by returning a unique token. Guest have to verify the credential once and in return they will get a unique token which is allowed to access for 10 minutes. The token will have user’s basic details and role details. When registering a user and resetting a password the password entered is encrypted (using bcrypt) and stored in the database. Even when querying we can get only the highest version of the password unless specially quarried for the real password. User can request to reset the password then a hashed reset token will be generated and an email will be sent to the user’s email address along with the reset URL. Once user visit the reset URL, server checks the validity of the reset token and allows to change the password.
Since the authentication is developed as a service, the buyer service and the seller service requires to be
authenticated externally. For this the buyer service and the seller service will be using a middleware to
send a request to the authentication service to validate the bearer token sent in request headers
through the WSO2 EI (ESB).
“Authenticate” middleware in the buyer/seller service is used to validate the response that is returned
after requesting the authentication service with authorization token in request headers. If the response
sent from the authentication service has a user, it will be added to the request object and the next
function will be invoke.
Function “getAuthUserFromBearerToken” is used in the buyer/seller service to request the
authentication service with the authorization token(JWT) and return back the response. The request will
be sent through the ESB.
Function “validate token” is used in the Authentication service to validate the token sent in the request
body and if the token is verified, user will be retrieved and returned.
If the token is valid then the user will be added to the request object in the Buyer and Seller service.
Since the role “seller” must be validated in the seller service another middleware is used to validate the
role in the request user.
In order to provide extra security when making a payment through credit card gateway or mobile payment gateway, order details along with the transfer amount will be hashed. When the user is paying through credit card / mobile then a request will be sent to the gateway with transfer amount and order id. Since these data could be changed, another parameter is sent which is a hashed value generated using the order id, transfer amount and order secret key. Order secret key will be saved in environment configurations in both the services. The payment gateway will hash the data received (transfer amount and order id) with the order secret and generate a hashed value. If this value and the hashed parameter sent along with the data matches then the payment is secure and can be made. (In real scenario payment gateways will use the Client User ID and Secret received when registering to the gateway) Also after completing the payment, gateway will send a request to the buyer service with the data such as order id, transfer amount and payment hash code. Payment hash code is generated using the order id, transfer amount and payment secret key. Payment secret key will be saved in environment configurations in both the services. Then the buyer service will validate and compare a payment hash codes and if valid the order payment will be updated as paid and notifications will be sent through mail and SMS.
