Assignment Handout
Contributors: Alicia Wang, Conner Swenberg
Last updated
Contributors: Alicia Wang, Conner Swenberg
Last updated
Due Date: Monday 10/28, 11:59pm EST
You will be building a Venmo-style peer-to-peer payment app. For now, this app will have users that can send money to each other.
We have provided the starting files you will need to complete this assignment for your convenience. This also simplifies your submission by just having to zip this same folder.
We have shown you how to use the Flask framework to set up routes and respond to network requests. Your assignment is to implement a series of routes following the provided specification for responding to sample requests. If you are struggling with the assignment, we recommend referring to the Demo to see a concrete example.
API Specificationdb.py
Reference the Demo for specifics on connecting to our Sqlite3 database file, venmo.db
, and writing SQL command executions with the sqlite3
package import. Implement methods for initializing the DatabaseDriver (__init__(self)
), creating your user table, querying, inserting, updating, and deleting from the user table.
Note: we have examples of SQL syntax in both the Lecture and Demo of this chapter!
app.py
Reference the Demo for specifics on defining route syntax. We recommend approaching routes in the order they appear in the API Specification. After defining your route and function to return a response, open up Postman and test your route. Testing with Postman simply involves creating a new request tab, entering your server's URL, choosing a request method, and clicking the Send
button.
After creating all of your routes to satisfy API Specification (and checking with Postman as you create each route), you should run our testing script to confirm that everything is working properly.
A README.txt
file is included in the starter code for you to fill out after completing the assignment. Also note that you will not receive extra credit for extra credit challenges you complete if you do not let us know for when we grade!
Common mistakes in styling are:
NOT HAVING documentation/comments in each of your methods
Naming variables with CamelCase instead of snake_case
Too much/too little empty spaces/empty lines
Leaving in commented code
Take some time looking through the guide to learn how to make tests using Postman. You should submit your Postman collection along with your CMS submission. The best way to get full credit for your tests is to ensure that you check that the response from your API matches what the API specification is expecting to receive. Please make sure that all your tests pass when we run your collection (make sure to clear your database before running to ensure you get the result we will get).
While that should be enough to get full credit, your tests can be cleaner and easier to change if you use variables or environments. It's up to you how much you want to learn and incorporate into your tests - the better you get at it the easier the assignments will be in the future and the likelier your API will pass the test cases we release on the first try.
If you'd prefer to learn how to use Postman through a video, here is a link to everything you'll need to know for this class; however, the audio quality is quite poor due to a technical error. If you think you would benefit from a re-recording of a Postman demo, indicate that on the feedback form and we will be happy to record one.
Next, zip the starter folder and submit on CMS. For reference, your directory structure should look like the following:
For clarification, this means that you SHOULD NOT include your virtual environment, pycache, or .db file in your final submission. Doing so will lose you a few points on the project.
To receive credit for your assignment, you must fill out the feedback form so that we can better understand how effectively we are teaching and how long students are spending on assignments.
Students will most benefit from our class time if they come in with a few things done.
Pre-Class TODO's+0.5 points for implementation +0.5 points for README explanation
Passwords
We don’t want users to have unauthorized access to other users' balances. Please change how you model your database and add extra credit routes to support users having passwords. Require a user’s password in the request’s body when
attempting to create a user POST
/api/extra/users/
getting a user POST
/api/extra/user/{id}/
sending money POST
/api/extra/send/
Include proper error handling (401 Unauthorized) if no password is sent or if it's incorrect. In addition, include in your README.txt
why it is important that these routes require authorization.
+0.5 points for implementation +0.5 points for README explanation +1 point more if all of Tier I completed
Password Hashing
You probably saved your passwords in plain text in the tier I challenge. That’s a big no-no in industry! Research what password hashing is and add the functionality to previous routes requiring a password (some suggested libraries include hashlib). In addition include in your README.txt
why password hashing is important.
+0.75 points for implementation +0.75 points for environment setup +0.5 points for README explanation +1 point more if all of Tier I & II completed
Securer Passwords
While hashing passwords is a good step towards having our passwords be stored more securely, it's not enough. Try to hash a simple password (like "password123") using this and then try to crack the password using this. Do some research to answer the following questions in your README.txt
What are rainbow tables and how do they work?
What is password salting and how can it protect against rainbow tables?
What is iterative hashing and how can it protect against rainbow tables?
Once you've done your research, actually add salting and iterative hashing functionality to previous routes requiring a singly-hashed password. One thing to keep in mind is that if we were to expose our codebase to the public (like our open-source apps), our salt and number of iterations are visible and our hashed passwords are vulnerable to being cracked. We can resolve this issue by having a secrets environment file which will contain this sensitive information.
For our project to recognize our secrets file, we need a way to load the environment file when inside our directory to access our defined variables and to unload the environment file when outside our directory to clean up our environment. To accomplish this, install direnv which takes care of this for you (and can be used for every language). Once you've installed this successfully, create a file named .env and write the following
where PASSWORD_SALT is some text that is at least 32 characters long and NUMBER_OF_ITERATIONS is at least 500. Now, to access these environment variables you can refer to this in your project to retrieve the values.
With your new secrets file, you can now make your code open-source (e.g. a public repository on GitHub which you will learn about later in the semester) since it pulls from your .env file which you store in a secure location! Please include your .env in your submission (you can trust us) so we can run your code.