calebthewood / flask-warbler

Warbler

A twitter clone, built in Python-Flask.

View Demo · Report Bug · Request Feature

Table of Contents

1. About The Project
   • Built With
2. Getting Started
3. Usage
4. Roadmap
5. Contact
6. Acknowledgments

About The Project

Warbler is a paired-down twitter clone I developed while attending Rithm School. The a non-functional skeleton of the app was provided, and my primary goal was to implement the database tables and relationships needed to support users, follows, likes, and messages. Since then I've continued to add to and refine the app.

I migrated the database from a Heroku Hobby Dyno to an RDS instance. I revamped buttons in the app to add AJAX and make them reactive. Currently, I'm working on adding a comments system to allow commenting on a message.

(back to top)

Built With

• Flask
• SQLAlchemy
• WTForms
• Jinja
• PostreSQL
• JWT
• Bootstrap
• JQuery

(back to top)

Getting Started

Clone GitHub Repo

$ git clone https://github.com/calebthewood/flask-warbler.git

Create a .env file to hold configuration:

SECRET_KEY=abc123
DATABASE_URL=postgresql:///warbler

Create a Python virtual environment and install dependencies in local dir

$ python3 -m venv venv
$ source venv/bin/activate
(venv) $ pip install -r requirements.txt

Create Postgres database in PSQL

$ psql
  CREATE DATABASE warbler
  (ctrl-d to exit psql)

Load env variables

(venv) $ ipython
In [1]: from dotenv import load_dotenv
In [1]: load_dotenv()  # take environment variables from .env.
In [1]: %run seed.py

Run server on local host port 5001

(venv) $ flask run -p 5001

Usage

WIP

DB table summary:

• follows: a through table with foreign keys from users, user_being_followed and user_following, comprising the table's composite key.
• likes: a through table with foreign keys from users and messages where each record represents a single user's "like" of a message.
• users: table storing data regarding user, model includes joins for follows, followers, likes, and messages
• messages: table storing messages with a join on users.

Security:

• authentication: JWT
• encryption: bcrypt
• CSRF protection: WTForms

(back to top)

Roadmap

• Custom 404 page
• Add AJAX
  • liking a warble
  • post msg modal
• DRY up things
  • Templates
  • Authorization
  • URLs
• Optimize Queries
• Make a change pswd form
• Allow “Private” Accounts
• Add Admin Users
• User Blocking
• Direct Messages

See the open issues for a full list of proposed features (and known issues).

(back to top)

Contact

I'm Caleb, Web Developer and Fullstack Enginner. Questions?

• On twitter at @calebthewood
• Personal Site: calebwood.dev
• email: [email protected]

(back to top)

Acknowledgments

• Rithm School
• FontAwesome

(back to top)

flask-warbler's Issues

Custom 404 Page

Current 404 is the flask default. Create a custom 404.

Add Admin Users

Add a feature for “admin users” — these are users that have a new field on their model set to true.

Admin users can:

• delete any user’s messages
• delete any user
• edit a user profile; when an admin user edits a profile, they should be able to see and set the “admin” field to make another user an admin

Error: Invalid Salt

Logging in sometimes produces the following error. Likely related to updating bcrypt library.

Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 2095, in call
return self.wsgi_app(environ, start_response)
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 2080, in wsgi_app
response = self.handle_exception(e)
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 2077, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 1525, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 1523, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 1509, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**req.view_args)
File "/Users/calebwood/Desktop/Rithm/projects/flask-warbler/app.py", line 106, in login
user = User.authenticate(form.username.data,
File "/Users/calebwood/Desktop/Rithm/projects/flask-warbler/models.py", line 165, in authenticate
is_auth = bcrypt.check_password_hash(user.password, password)
File "/usr/local/lib/python3.9/site-packages/flask_bcrypt.py", line 225, in check_password_hash
return hmac.compare_digest(bcrypt.hashpw(password, pw_hash), pw_hash)
File "/usr/local/lib/python3.9/site-packages/bcrypt/init.py", line 105, in hashpw
raise ValueError("Invalid salt")
ValueError: Invalid salt

Optimize Queries

In some places, Warbler may be making far more queries than it needs: the homepage can use more than 75 queries!

Using the Flask-DebugToolbar, audit query usage and fix some of the worst offenders.

Add AJAX

There are two areas where AJAX would really benefit this site:

• When you like/unlike a warble, you shouldn’t have to refresh the page
• You should be able to compose a warble via a popup modal that is available on every page via the navigation bar button.

Allow “Private” Accounts

Add a feature that allows a user to make their account “private”. A private account should normally only the profile page without messages.

You can follow a private account — but that user will need to approve your follow. At the point you are successfully following a private account, you should then be able to see their messages.

Note: this will require some schema changes and thoughtful design. Can you do this in a way that doesn’t sprinkle (even more) if conditions around? Can you add any useful functions on the User or Message classes?

DRY Up the URLs

Throughout the app, there are many, many places where URLs for the app are hardcoded throughout – consider the number of places that refer to URLs like /users/[user-id].

Flask has a nice feature, url_for(), which can produce the correct URL when given a view function name. This allows you to not use the URLs directly in other routes/templates, and makes it easier in the future if you even needed to move URLs around (say, is /users/[user-id] needed to change to /users/detail/[user-id].

Learn about this feature and use it throughout the site.

Direct Messages

Add a feature of “direct messages” — users being able to send private messages to another user, visible only to that user.

There are lots of possibilities on how far you want to take this one.

DRY Up the Templates

There’s a lot of repetition in this app!

Here are some ideas to clean up repetition:

• Learn about the {% include %} statement in Jinja and use this to not have the forms be so repetitive.
• Learn about the {% macro %} and {% import %} statements in Jinja; you can use these to be even more clever, and get rid of a lot of repetition in the user detail, followers, followed_user pages, and more.

User Blocking

Add a feature where users can block other users:

• when viewing a user page, there should be a block/unblock button
• blocked users view the blocker in any way

Make a Change Password Form

Make a form with three fields:

current password
new password
new password again, for confirmation
If the user is logged in and they provide the right password and their new passwords match, change their password.

Hint: do this by making a new method on the User class, rather than hard-coding stuff about password hashing in the view function.

Comments

Draft implementation plan for Comments. Consider the following:

1. DB Table and Schema
2. Templates
3. Display/Hide functionality
4. What screens to show/hide by default

DRY Up the Authorization

This will be more advanced.
In many routes, there are a few lines that check for is-a-user-logged-in. You could solve this by writing your own “decorator”, like “@app.route”, but that checks if the g.user object is not null and, if not, flashes and redirects.

You’ll need to do some searching and reading about Python decorators to do this.