CSE312-Team Project Requirements Solved

 

Open-Source Reports
Create a directory in your repository named “reports” that contains all the open-source reports for your project. Review the project section of the course website for details on what each report must contain. You need a separate report for each technology you use in your project that would not be allowed on a homework assignment.

 

*You do not need a report for jquery, but you do need a report for any front-end frameworks you use.

Below are explicit lists of libraries that do/don’t require reports. This list will be updated as students/teams ask about other libraries

 

Libraries that do not require reports:

 

●      Any library that is allowed on a HW assignment. This includes TCP libraries, concurrency libraries, bcrypt, JSON libraries, database client connection libraries, docker and any other library explicitly allowed for HW

●      Jquery

●      Bootstrap + other styling-only front end libraries

●      Client-side Socket IO

●      Reddis

●      Secrets (Or any library that generates tokens with high entropy)

 

Anything not included in the list above does require a report. To answer some common questions, the following do need reports:

 

●      Front end templates (If you use a free template for your front end, it is important to write a report to include any licensing and/or terms of service attached to that template)

●      Front end frameworks (React, Angular, Vue, etc). Anything done by these frameworks beyond what you can do with JavaScript + Jquery must be documented in a report. The report must include the interactions between the library and your server as well as anything you had to do on a HW (eg. HTML templating, AJAX requests, WebSocket connections). Features that only include styling do not have to be included in your report.

●      Server-side Socket IO (And other server-side Web Socket libraries)

●      HTML template libraries (Includes Django Crispy) or any library that generates HTML

●      Database modeling libraries (incluses Flask-SQLAlchemy and Django modeling) or any library that generates your database queries for you

●      Django channels (Including how Reddis is used by channels)

 

 

 

Docker-Compose

Your app must be setup to deploy with docker-compose. In the root directory of your repository include a docker-compose.yml file with everything needed to run your app using docker-compose. At a minimum this must include creating a container for your database and another container for your app that will communicate with the database container.

 

●      You may choose the local port for your app unless otherwise directed

 

When testing or deploying your app the procedure will be:

 

Clone your repository
cd into to the directory of the repository
Build the docker image (docker-compose build)
Create and run a docker containers (docker-compose up --detach)
Open a browser and navigate to http://localhost:<local_port (We’ll read your docker-compose.yml to find your local port)
 

 

 

Deployment
 

Deployment Servers: You are required to deploy your project so that it is available on the Internet. To facilitate these deployments, CSE IT will be providing server space on CSE servers. You must deploy on this provided server.

 

Your machines are setup and you have a machine named cse-XX.dcsl.buffalo.edu where you will deploy your app. These machines are only accessible from UB’s network. To connect to the machine you can either 1. Connect to the UB VPN or 2. ssh into karels, where you changed your password, karels then ssh from karels to your machine. Anyone visiting your app will also need to be connected to the UB network so when you share the link with others, make sure they understand this. Your password on your machine is the new password you set on karels.

 

Use port 80 when you deploy your app such that http://cse312-XX.dcsl.buffalo.edu will access your app.

 

Server name: cse312-XX.dcsl.buffalo.edu

 

Changing Passwords: Use ssh, or putty, to log into this server. Your initial password has been set to you birth date (MMDD) followed by the last 6 digits of your UB card number (Note that this is the 16 digit number on your UB ID card, not your person number which is 8 digits long).

 

Log into this server as soon as possible change your password using the command “passwd” and set it to a password that you don’t use on any other machine. This is important as you and your classmates will have sudo access to this machine. As such, you should treat these machines as compromised and not store any sensitive data on the server.

 

Once everyone changes their password CSE IT will begin setting up individual VMs for each team where you can deploy your app.

Requirements
 

Below is more description of each of the 5 criteria listed on the course website. 

 

●      User Accounts with Secure Authentication

○      Users must be able to register accounts and log into their account. Once logged in, each user must see at least some content and functionality that is specific to them and cannot be accessed by other users (If you completed DMs then this is covered)

○      Each user must have at least 1 setting that they can adjust. This setting must persist across sessions. For example, if a user logs in and changes this setting it should still be changed when they log off and log back in from a different device

○      Requires use of a database in Docker to store uploads (Services such as FireBase are not allowed)

○      OAuth is allowed (Report required!), though you still have to store a profile for the user with their setting(s) on your server

●      Users to see all users who are currently logged in

○      It is up to you what feature(s) you want to implement for this requirement, though there should be a way to see all other logged in users.

○      It is ok if this list only reloads when the page is loaded/reloaded

●      Users can send direct messages (DM) to other users with notifications when a DM is received

○      From the previous requirement, each user is able to “see” other users. There must be an option to be able to DM users where you can see them.

○      DM’s can be text-only

○      When a DM is received, the recipient must be notified in real-time and given an option to reply

○      You may assume the recipient is online at the time the DM is sent

○      DMs do not have to persist

○      Receiving a DM can be as simple as a message that appears anywhere on the screen and it can be replaced when another message is received and it is ok if it disappears after the page is reloaded

●      Users can share some form of multimedia content which is stored and hosted on your server

○      Requires use of a database in Docker to store uploads (Services such as FireBase are not allowed)

○      The multimedia content itself can be stored as files on your server with the file paths stored in your database

○      The details of the content are up to your team to design as long as multimedia is shared in some way (Ex. Uploading profile pictures which other users see is acceptable)

●      Live interactions between users via WebSockets (Cannot be text)

○      Users interact in real-time via WebSockets. This cannot be raw text (ie. you can’t build a chat app like we saw in lecture)

○      The WebSocket messages can be formatted as JSON Strings, so long as the feature from the user perspective is not sharing plain text with other users.

○      Example: You build a game where user locations are shared via WebSockets allowing all players to see other players move in the game world.

○      Example: A shared canvas on which users can draw and see each other’s drawings