CSE 216: Software Engineering Programming Assignment #2 Instructor: Prof. Liang Cheng Posted: 2/26/2021 Project Assistants (PAs)/Mentors: Andrew Ha, Thanos Kougionis, Maximillian Machado, Buckley Ross
Due: 3/19/2021
Problem Statement
Well, that escalated quickly. The CTO saw your web app and said ¡°I want that.¡± He insisted that you launch it immediately, but you managed to buy enough time to go from ¡°prototype¡± to ¡°barely adequate.¡± On the bright side, while he said you only had two weeks before you went live, he accepted your advice to add features incrementally. But at the very least, it¡¯s going to be important to add authentication and a comment system.
It¡¯s going to be important to move quickly. But more importantly, you need to make sure that each step is done right… this project is going to get bigger and bigger, and any technical debt you accrue now is going to cost a lot to pay off later on down the road.
You talk with the folks in IT, who talk about the company¡¯s switch to Google Apps for Business, and how Google¡¯s implementation of OAuth 2.0 [1] has made password resets a thing of the past for almost every system in the company. But the password resets are just too big of a problem, and you¡¯ve got to do something quick. You take a look at the Google API Console [2], and it looks tantalizingly easy…
Reminder
Each student should be in a different role than the one during Phase 1. The design for this phase (Phase 2) will be an in-class exercise. The class will discuss, and coalesce around, a single design.
Deliverables
The Back End
Your job is to implement an OAuth flow in the back end, so that clients can authenticate with Google. We have discussed how to do this in class, to help you get started. It will be a good idea to do this as early as possible, since your teammates are depending on this code.
One aspect of this task that can be confusing is that your back-end server will get a token from Google, and that token will have an expiration date. We do not need to worry about the expiration, though: once the user has authenticated, that¡¯s good enough for us… we won¡¯t be making subsequent requests to Google APIs using that token. Once the user is authenticated, you can save the user ID and a random session key into a local hash table.
You will probably want to read the Google documentation on Backend OAuth implementation [3]. Note that for the purposes of this assignment, you should only allow use from the lehigh.edu domain. You do not need to implement a ¡°registration¡± phase anymore: anyone at lehigh.edu should immediately have access to The Buzz.
We will no longer have anonymous browsing of the messages on ¡°The Buzz.¡± Users must be logged in to view posts, up-vote, down-vote, and have the ability to leave comments. Note that comments won¡¯t be nested.
Regarding votes, we will provide votes as a state machine. Initially, a user has a neutral vote. Clicking up- vote or down-vote will act as expected. However, up-voting a post that the user has already up-voted, or
down-voting a post that the user has already down-voted, will result in no change. Down-voting a previously up-voted post, or up-voting a previously down-voted post, will replace the previous vote. You must think carefully about how to do this in SQL.
Votes must be secure. It should not be possible for a user to dissect the JSON and see who has up-voted or down-voted a post. However, you might choose to allow a user to see which posts she up- or down- voted.
The Web Developer
Your app should support all of the above features of the server. You¡¯ll need to have a login page via OAuth, up-votes, down-votes, and comments using the new JSON formats and new REST routes. A user should be able to edit the comment(s) posted by the user (which means more REST routes… be sure to coordinate with the back-end developer).
In addition, you are going to add a profile page, which will show the user name, user email, and a comment about the user. A user should be able to visit profile of the author of any message or comment. It should also be possible to visit one¡¯s own profile page. And, of course, you should be able to get to your profile page from the Bootstrap navbar at the top of the page. Clicking on the name of a person who posts a message, or who makes a comment, should take you to their profile page. On any profile page, a user should be able to see all of the posts that the given profile has posted.
Note that you will be modifying and adapting code that your team member wrote in a previous phase. If your team member adhered to good standards, you should follow suit. If not, you should refactor the older code to match the quality of the code you write.
The Admin App
Of course, you will also need to have a way to manage the new tables and new columns in the existing tables in your database. Once you have those tasks done, it will be your responsibility to help the project manager to keep everything on track, by pair programming with your teammates.
Moreover, the admin app developer can help teammates to develop a good testing strategy as the testing ¡°czar¡±. In this role, the admin app developer will review teammates¡¯ tests, and advise them on deficiencies and invalid assumptions.
The Project Manager
The project manager should create a new Google account that can be used to ¡±host¡± the project. Using this account, the project manager should set the authorized JavaScript origins, authorized redirect URIs, and Android Studio instances. You will have multiple client IDs to set as the ¡±audience¡± but only the server¡¯s client ID/secret will be used for the redirect URL and Open ID Connect code redemption.
With the app running on Heroku and following the principles of 12-factor app design, you¡¯re starting to have a lot of configuration variables to maintain. That¡¯s just a fact of life, but you should document the configuration carefully.
In addition, the Project Manager is still responsible for integrating each member¡¯s code into the main branch, performing code reviews and documentation, and submitting the team¡¯s work. Remember: tests are important, and should not be delayed. Finding bugs early is much better than finding them late!
Code reviews are going to be extremely important for this step. In particular, you should study OAuth on
your own, so that you can be sure that your developers are using it correctly. Are the keys from Google being used correctly? Are secrets being kept secret? Can the user fake her credentials? Can the server spoof a user? Once a program uses external APIs, code reviews become harder, because you need to review API usage (and you need to test for correct usage too). The programmers write less code, since they aren¡¯t implementing things themselves. But as the project manager, your job gets a little harder.
In addition to the database and routes, you should also create documentation for the user interface for your app. Be sure to document the flows related to authentication.
The project manager continues to explore ideas to extend the project for a potential start-up and researches on what the target users/markets are. Brainstorm with team members so that the team has a storyboard. Fill in the template provided for Design-oriented Thinking for this phase; the template is available in the CourseSite.
Lastly, note that this is an opportunity to refactor. The next phase will have many more deliverables than this phase, so the more resilient your code is, the easier that phase will be. You should make a plan for how your team will get rid of technical debt and be in a good place moving on to the next phase.
Mentorship
Each team has already had one Project Assistant (PA) assigned as a mentor, and that PA will meet with students at least once per week, both to mentor the team and to assess its performance. Teams should take advantage of this opportunity, especially when it comes to teamwork, priorities, and technical obstacles.
Turn-in Instructions
We will make a copy of your team¡¯s repository at some point on or after the due date. Be sure to commit and push your solution prior to the due date by branching from master into a new branch called ¡°phase2¡±. If your team completes all the tasks, your last commit to the Phase2 branch should contain the message ¡°All tasks complete, ready to be graded¡±. This will be viewed as a submission, and any future commits will not be included in your grade.
Late Submission Policy
If you do not push a commit with the message ¡°All tasks complete, ready to grade¡± then a snapshot of your repo will be taken by the 4th day after the deadline and used for grading. The following policy will be used for grading late submissions.
Submission late for 1 day: 15% penalty; Submission late for 2 days: 30% penalty; Submission late for 3 days: 45% penalty; Submission late for 4 days: 60% penalty;
A submission late for more than 4 days will not be graded thus receiving 0 point.
Acknowledgments
The creation and updates of this project were funded in part by the Kern Entrepreneurial Engineering
Network [4]. We thank Professor Michael Spear and the Kern Family Foundation for making this project possible, and we encourage our students to emphasize the ¡°Three C¡¯s¡± in all aspects of this project.
References
[1] OAuth2.0. OAuth Community Site, 2021. https://oauth.net/.
[2] Google, Inc. Google API Console, 2021. https://console.developers.google.com/.
[3] Google, Inc. Authenticate with a Backend Server, 2021. https://developers.google.com/identity/sign- in/web/backend-auth.
[4] The Kern Family Foundation. KEEN-Engineering Unleashed, 2021. http://engineeringunleashed.com.