chefboyrd package


chefboyrd.auth module

Module for authentication and authorization

  • written by: Zachary Blanco
  • tested by: Zachary Blanco
  • debugged by: Zachary Blanco

Uses the flask-login plugin as well as some custom wrapper functions to ensure that logged in users are only able to access authorized resources.


Logs a user into the application


‘Logs a user out and renders the login template with a message


Wrapper around the login_required wrapper from flask-login

This allows us to keep the same style and also not have to have multiple imports for roles and require_login

chefboyrd.auth.require_role(role, **kwargss)[source]

Decorate a function with this in order to require a specific role(s), to access a view.

Also decorates a function, so that you must pass the current user’s role into it’s first argument if it’s needed.

By decorating a function with @require_role you are implicity forcing @login_required as well. Example:

def view_dash():
# Something here

def view_dash(role):
Parameters:role (list or str) – A single role name or list of role names for which users are allowed to access the specified resource

If a user is not authorized then the flask_login.unauthorized handler is called.


Function to handle requests to resources that are not authorized or authenticated.


Loads the user via a DB call

Parameters:email (str) – The email to load
Returns:The user object corresponding to the email passed, or None if it doesn’t exist
Return type:User

Module contents

Main file to register blueprints and run the flask application

written by: Zachary Blanco, Jeffrey Huang, Seo Bo Shim, Brandon Smith, Jarod Morin tested by: Zachary Blanco, Jeffrey Huang, Seo Bo Shim, Brandon Smith, Jarod Morin debugged by: Zachary Blanco, Jeffrey Huang, Seo Bo Shim, Brandon Smith, Jarod Morin

This is where most of the app setup is done. We shouldn’t have to modify this file except for two different cases:

  1. We are adding new views to the application
  2. We are adding new models to the application

Otherwise this file should not be touched.

Every view which is to be part of the app must be registered appropriately using:

APP.register_blueprint(viewpage, ...)

Other args to register_blueprint might include the url_prefix if you want your pages to reside on a specific path.

If models are being added we just need to make sure the corresponding tables are created (if they don’t already exist) when starting the application. We do this by making the call


The True argument forces any failures to be silent when creating the table - i.e. not crash the application. Other than that we shouldn’t need to add much else to this file.

Please see the following files for examples of each part of the MVC structure of this project

  • Model ==> models/
  • View ==> views/
  • Controller ==> controllers/

Other helpful sources of documentaiton and reading:


Close the database connection after each request.


Connect to the database before each request.


‘Renders the default template