Login-Register

This GitHub repository contains code that powers both the frontend & backend of logging in and registering users into Megagram. Megagram is a blend of some of the features of Instagram and Amazon, combined into a single website. It was created by me, Rishav Ray, as a personal project to acquire and then showcase my skills. To allocate my time efficiently, I focused on three of the nine key repositories of Megagram —Login-Register, Reset-Password, and Home-Page— which when combined fulfills my purpose of the entire endeavor. I also focused on the WorksPresentation Github repository of mine(which has a wiki with important info), containing a complex frontend that acts as a website about me for job-recruiters and employers to view!

Welcome aboard!

Table of Contents

0. Important Disclaimer
1. Key Points on Frontend
2. Key Points on Backend
3. Key Points on Data
4. Key Points on Cloud
5. Video-Demonstration of Frontend
6. Finale(My Contact Info is Here)

Important Disclaimer because Honesty is the Best Policy

During the first iteration of Project Megagram, I worked on all nine repositories. In the second iteration, I narrowed my focus to three of them, including this Login-Register repository. In the third and final iteration, I continued concentrating on these three repositories. However, I chose not to fully revise and polish all the frontend and backend files across them, as the work(which I was not paid at all for) felt repetitive and offered limited new learning and 'showing-skills-to-future-employer' opportunities. Furthermore, all the cloud-services that my project so heavily relies on were out of my budget.

To combat the issues above, I used the final iteration to create detailed wiki pages in my WorksPresentation Github repository. These documents outline how I would approach various aspects of frontend, backend, cloud architecture, and more, if I were tasked with building them under real-world conditions.

As a result, the current state of the content in this repository(including the rest of the README below) may not fully reflect industry-grade optimization or deployment readiness. Rather, it represents earlier work, with my more refined thought process and technical strategies documented in the associated wiki pages.

Key Points on Frontend

• The frontend is powered by Python Django and is located in the login_register_frontend directory in this Github repo.

• Inside login_register_frontend will be my_app, which contains the static folder and the templates folder necessary for this project. Templates are written in HTML, and static includes JavaScript-files, CSS-files, an images folder, and a fonts folder.

• There are 4 endpoints: /login, /register, /age-check, and /confirm-code. All the endpoints start with https://project-megagram.com/login-register/.

• Each of the frontend pages work for both dark-mode and light-mode of the system, and have been successfully tested across the top 5 most popular browsers and across the different screen-sizes provided by Google-Chrome Dev-Tools.

• The JavaScript utilizes JQuery to a significant extent due to its concise syntax and grand popularity in the world of web-frontends.

• The frontend utilizes Google-Cloud for its reCaptcha and OAuth services. Specifically, it utilizes reCaptcha to verify that user-login-attempts aren't done by a robot. The OAuth services give users the ability to create accounts and login to Megagram via their Google accounts. Disclaimer: these weren't actually implemented by me due to financial constraints, however, I detailed out exactly how I would've done them in the wiki!

• You can append ?language=Italiano or ?language=日本語 to the URL to trigger backend calls for translations via a language-translation API. For translations that are already cached in Redis, the backend directly returns that instead of spending money and API-usage-tokens on the RapidAPI DeepTranslate API Service.

• Whenever the user tries to access an endpoint in the frontend that does not exist, they will come across a 'Page-Not-Found' page that is very well styled. It was created by an impeccable Graphics designer and the styling is very exquisite and complex, but I was able to alter the HTML/JS/CSS just a bit so that it fits the 'Megagram' brand.

Key Points on Backend

• The backend is powered by Python Django and is located in the login_register_backend directory in this Github repo. It supports the methods 'GET', 'POST', 'PATCH', & 'DELETE'.

• There are 14 endpoints, presented in the screenshot below. All the endpoints start with https://project-megagram.com/api/login-register/.

• The backend utilizes rate-limiting on each one of its endpoints(and the rates can vary per endpoint). For instance, some endpoints(specifically /updateUser, /removeUser, and /loginUser) have rate-limits much lower than the other endpoints for the sake of security- 5 per hour based on ip-address and user-id. This is because the /updateUser and /removeUser endpoints both require user-auth-tokens and keeping the limit low makes brute-force-attacks much less likely to work. Similarly, For /loginUser, users need to send in the correct password, and keeping the limit low significantly hinders brute-force-attacks.

• For the usersTable, the backend uses a Django model(User) and serializer(UserSerializer). For accessing the userAuthTokens table it uses a google-cloud-mysql-spanner client. For accessing the 'Usernames and their Info' Redis hashset, it uses the Redis-connection that was configured in settings.py as the default(which is also used by Django for rate-limiting).

• The /updateUser, and /removeUser endpoints both require user-auth-tokens to proceed. The /createUser endpoint provides the newly-created user the user-auth-tokens to proceed(i.e it creates the account and logs in the user on their browser). The /loginUser endpoint enables the user to log in by refreshing their userAuthToken and userRefreshToken and setting their HTTP-only, same-site-strict cookies; logins only work if the provided password by the user to the endpoint is correct.

• For encrypting/decrypting user-data(specifically the 'contactInfo' for all users, and the 'accountBasedIn' and 'dateOfBirth' for users with isPrivate set to True), the backend uses Google-Cloud Key-Management-Service. Specifically, it uses a global key-ring called 'usersTableMySQL'; each row in the 'users' Table corresponds to an id(which is an integer representing the user-id), and the stringified id is used as the key-id for encrypting and decrypting the specific columns of each user-row.

• There are 18 helper methods in the backend that are not directly accessible via the Rest API but are used by the methods that are accessible via the Rest API. For the sake of organization of views.py, first all the Rest API methods are listed and then all the helper-methods. Below is a screenshot of the names and parameters of all 18 helper-methods.

Key Points on Data

• For this repository, there's one locally-hosted MySQL table called 'users'; one MySQL table hosted via Google Cloud MySQL-Spanner called 'userAuthTokens'; there's also an AWS-Redis cache for three purposes in this website. More on that later in this section.

• You can connect to the Locally-hosted MySQL Database with read-only-access via the following details: host: 'ngrok(update this later)', username: 'spectator', password: ''(no password). You can also connect to the AWS-Redis Cache with read-only-access using host: 'redis-14251.c261.us-east-1-4.ec2.redns.redis-cloud.com:14251', username: 'spectator', & password: 'SPECtator1!!'.

• The 'users' table has fields that can be described in the screenshot below. Users must be at-least 10 years of age and the accountBasedIn field must be either a US-State, a country, or 'N/A'/'Temporary'. The password must pass a strength test and is only stored in the database after salting and hashing it(i.e user passwords are not stored as plaintext).

• The 'userAuthTokens' table has the following fields: hashedAuthToken(45-character-string), authTokenSalt(45-character-string), hashedRefreshToken(45-character-string), hashedRefreshTokenSalt, authTokenExpiry(timestamp), and refreshTokenExpiry(timestamp). Auth tokens(last 45 min) are used in cookies and backend-servers to prove authentication required for certain requests(i.e updating/deleting an account), and refresh-tokens(last 7 days and also used in cookies) are used to refresh auth-tokens that have expired. Once both the refresh token and auth token are expired, the user needs to re-login.

• The three purposes of AWS-Redis for Login-Register are as follows: (1) For rate-limiting all the different endpoints of the backend. (2) For using hash-sets named something like 'Translations from English to Español' which stores key-value pairs where keys are English words and values are their Spanish translations. This is used by the frontend for translating the website; this hash-set aids in efficiency and reducing money/usage-tokens spent when making requests to the Rapid-API Deep-Translate API service. (3) For using the hash-set 'Usernames and their Info' which contains keys that are usernames of Megagram-users and values that are stringified dicts that contain their info(i.e all the other fields of the user in the 'users' table). This hash-set enables efficiency in fetching user-info.

Key Points on Cloud

• For the Login-Register part of Megagram, the only cloud-service-provider used is GCP(Google Cloud Platform).

• Disclaimer: anything cloud-related wasn't actually implemented by me due to financial constraints, however, I detailed out exactly how I would've done them in the wiki!

• GCP is used by the frontend for reCaptcha and OAuth, and by the backend for encrypting/decrypting sensitive columns of the 'users' table with the help of Google-Cloud Key-Management-Service(and the keys are all rotated automatically every 70 days).

• GCP is used for the GKE(Google-Kubernetes-Engine) Cluster, where the auto-scaling and loadbalancing of Kubernetes pods for both the frontend and backend takes place. You can find the actual Docker repositories in Docker Hub under rishavry/login-register-backend and rishavry/login-register-frontend.

• Last, but not least, GCP is used for the Managed Instance Group(MIG) called 'megagram-server-group'. This MIG has auto-scaling enabled and each instance in this group has a startup-script(located in this repo as megagram-server-startup.sh) that uses nginx to handle traffic at port 443. The nginx routes requests with /login-register/ and /login-register-api/ to the load-balancers in the GKE Cluster mentioned in the earlier point. the This MIG has a load-balancer that maps to port 443 of each instance in the MIG, and the ip-address of this load-balancer is the one that is directly associated with https://megagram.com!

Video-Demonstration of Frontend

Right here.

Finale

Thank you for sticking around till the end! Hope you found what you were looking for. Whether you did or did not, feel free to reach out to me using any of the following methods:

• Email: rishavray422@gmail.com

• Number(texting only): 608-443-7805

• Linkedin: https://www.fakelink.com