CSE 216: Software Engineering Programming Assignment #3
Instructor: Prof. Liang Cheng Assigned: 10/23/18
TA/Project Mentor: Dylan Gray, Connor Deppert, Kelli Frank, Charles Inwald, Alex Schuler
All Tasks Due: 11/05/18
Problem Statement
“Password Reset.” If you hear those words one more time, you’re going to scream. You are spending way too much time using the admin app to reset passwords for people who know not to write their passwords down, but who just can’t seem to remember them. 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 and Phase 2. Be careful with how you assign roles: each student should have a turn in each role before the end of the semester.
Deliverables The Back End
Your job is to implement an OAuth flow in the back end, so that clients can authenticate with Google, rather than using their Buzz-specific passwords. 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 key into a local hash table, just like in Phase 2.
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.
The Android App
You should use the GoogleApiClient and activity overlay to sign in [4]. Note that this can get complicated for your teammates, because this method requires a client ID that is specific to one team member’s Android Studio instance. There are tutorials online to help you to get this right.
If you haven’t yet, you should also add a profile activity. The 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. On any profile page, a user should be able to see all of the posts that the given profile has posted.
You should be mindful of duplication of code in this phase. You will be using a RecyclerView.Adapter,
just like in the main list of messages. Don’t copy and paste code. Instead, consider using an observer pattern. Depending on how your teammate wrote the code, this may mean implementing any listeners in the observer class and having all ”reactions” that occur on the UI thread occur there. If done correctly, you can use one class (the observer) in many activities to respond to things like Up/Down/Neutral votes. Note: If you keep any references to the activity/adapter in the observer, make sure you nullify those in the activity’s onDestroy or else there may be a memory leak.
The Web Developer
Your task is pretty much the same as the Android developer, except that the OAuth flow is a little bit simpler to implement for the web, thanks to the new “GoogleYOLO” library and one-tap authentication.
The Admin App
The admin app developer doesn’t have much to do, apart from updating the database schemas to provide the right columns for the new design. That doesn’t mean the admin app developer should slack off… instead, the admin app developer should discuss with the project manager and help teammates as much as possible.
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.
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.
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 TA/PA assigned as a mentor, and that TA/PA will meet with students 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 “phase3”.
Acknowledgments
The creation and updates of this project were funded in part by the Kern Entrepreneurial Engineering Network [5]. 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
- 0. OAuth Community Site, 2018.https://oauth.net/.
- Google, Inc. Google API Console, 2018.https://console.developers.google.com/.
- Google, Inc. Authenticate with a Backend Server, 2018. https://developers.google.com/identity/sign- in/web/backend-auth.
- Google, Inc. Integrating Google Sign-In into Your Android App, https://developers.google.com/identity/sign-in/android/sign-in.
- The Kern Family Foundation. KEEN-Engineering Unleashed, 2018.http://engineeringunleashed.com.
