Forem: Michael Bukachi

Random 1: Traefik blocks CORS by Default

Michael Bukachi — Wed, 18 Oct 2023 11:55:03 +0000

This is the first of a new series of really short blog posts that will touch on random things. Things I discover during my day-to-day activities.

I recently discovered that traefik (v2.9 at the time of this writing), blocks CORS requests by default. This issue can quickly be resolved by adding the right labels:

 - "traefik.http.middlewares.testheader.headers.accesscontrolallowmethods=*"
 - "traefik.http.middlewares.testheader.headers.accesscontrolallowheaders=*"
 - "traefik.http.middlewares.testheader.headers.accesscontrolalloworiginlist=*"

You can checkout more configurations options here

An "Easier" way to test Flask authentication?

Michael Bukachi — Thu, 01 Oct 2020 12:35:19 +0000

An "Easier" way to test Flask authentication?

Recently, I was on the testing train (for millionth time), walking towards the last carriages, trying to add and improve tests for one of my work projects when I stumbled upon this:

# def test_create_application(client: FlaskClient, mocker):
#     user = User.create(email='test@gmail.com', password=hash_password('test'))
#     with client:
#         client.post('/login', data=dict(email=user.email, password='test'))
#
#         res = client.post('/create_application', data=dict(name='test', identifier='http://test.com'),
#                           follow_redirects=True)
#         assert res.ok
#         assert b'Application added successfully' in res.data
#
#         # Test duplicate identifiers
#         res = client.post('/create_application', data=dict(name='test', identifier='http://test.com'),
#                           follow_redirects=True)
#         assert b'Identifier must be unique' in res.data

Let me say that I was bothered. Not by the commented out tests (yes, plural; the entire file actually 🙆‍♂️ ). Not by the fact that there were multiple assertions in a single test function. But by the sudden surge of memories of figuring out how to test flask views which are protected by authentication.

Heh! The stories I can tell!

Anyway, back to the code. One might say it's quite straight forward.

A user is created
We use the created user to login
We make some calls to specific views and do assertions with responses

Now, using the above mentioned steps should work for most (if not all) protected views.

Note: By views, we are referring to non-API routes i.e pages a user would interact within a browser.

But, there's more to this than meets the eye, especially in step 2.

For this web app, users would log in using an email and password. Under the hood, this would involve validating the user's credentials then modifying the current session by saving user information such as a unique user identifier or email. In a different web app, it might involve some form of external authentication. For instance, using an Oauth provider such as Google or Facebook or some kind of Lightweight Directory Access Protocol (LDAP) authentication.

Thinking about all this, one begins to realize that step 2 might not be a one-liner. For instance, in one of our apps, a user logs in using OpenID. We are planning to make this the default way of authentication for all our users.

Is there a "simple" way to approach this? A better way to tell your app "Hey, for the next number of x route calls, assume that the user is y".

This scenario, made me think about testing in Django. Yes, yes, I know that word is a taboo in the flask world 😆. Anyway, in "the name that must not be mentioned" test suite, there's a login method that allows you to log in a user without calling any URLs.

What if? Hear me out. What if we could "borrow" that functionality 🌚 . Take a look at the following sample web app:

from flask import Flask, request, redirect, url_for
from flask_login import LoginManager, UserMixin, login_required, login_user, logout_user
from werkzeug.exceptions import MethodNotAllowed, Unauthorized


class Config:
    SECRET_KEY = 'Some very long secret key'


class User(UserMixin):
    pass


login_manager = LoginManager()


@login_manager.user_loader
def user_loader(email):
    print('[[')
    if email != 'test@gmail.com':
        return

    user = User()
    user.id = email
    return user


@login_manager.request_loader
def request_loader(request):
    email = request.form.get('email')
    if email != 'test@gmail.com':
        return

    user = User()
    user.id = email

    user.is_authenticated = request.form['password'] == 'test'

    return user


@login_manager.unauthorized_handler
def unauthorized_handler():
    raise Unauthorized()


def create_app():
    app = Flask(__name__)
    app.config.from_object(Config)

    login_manager.init_app(app)

    @app.route('/')
    @login_required
    def index():
        return 'Ok'

    @app.route('/login', methods=['GET', 'POST'])
    def login():
        if request.method != 'POST':
            raise MethodNotAllowed()

        if request.form['email'] == 'test@gmail.com' and request.form['password'] == 'test':
            user = User()
            user.id = request.form['email']
            login_user(user)
            return redirect(url_for('.index'))

        raise Unauthorized()

    @app.route('/logout')
    def logout():
        logout_user()
        return 'Logged out'

    return app

We have a basic flask application with three routes:

One to log in
The root page, which is protected
And one for logging out

For the sake of this article, we are making the app as basic as possible. There are a lot of "best practices " violations 😨, bear with me. 😅

Here are the tests for the app:

import pytest
from flask.testing import FlaskClient

from app import create_app


@pytest.fixture(scope='module')
def flask_app():
    app = create_app()
    with app.app_context():
        yield app


@pytest.fixture(scope='module')
def client(flask_app):
    app = flask_app
    ctx = flask_app.test_request_context()
    ctx.push()
    app.test_client_class = FlaskClient
    return app.test_client()


def test_index_page__not_logged_in(client):
    res = client.get('/')
    assert res.status_code == 401


def test_index_page__logged_in(client):
    with client:
        client.post('/login', data=dict(email='test@gmail.com', password='test'))
        res = client.get('/')
        assert res.status_code == 200

We have two tests:

One verifies that an unauthenticated user cannot access the root page.
The other verifies that an authenticated can access the root page.

We are more interested in the second test.

What if we can make the second test something like:

def test_index_page__logged_in(client):
    res = client.get('/')
    assert res.status_code == 200

Where we do not have any of the login logic inside the test.

Well, good news, we have decorators in python.

If you are not familiar with decorators in python, feel free to take a look at the following article.

Let's introduce a decorator called force_login. Take a look at the following snippet:

def force_login(email=None):
    def inner(f):
        @functools.wraps(f)
        def wrapper(*args, **kwargs):
            if email:
                for key, val in kwargs.items():
                    if isinstance(val, FlaskClient):
                        with val:
                            with val.session_transaction() as sess:
                                sess['_user_id'] = email
                            return f(*args, **kwargs)
            return f(*args, **kwargs)

        return wrapper

    return inner

We are interested in the following lines:

with val:
    with val.session_transaction() as sess:
        sess['_user_id'] = email

Since we are using the Flask-login extension, we need to know how it tracks logged in users. Taking a look at the source code of the login_user we can see that it stores a couple of variables in the session:

def login_user(user, remember=False, duration=None, force=False, fresh=True):
    ...

    if not force and not user.is_active:
        return False

    user_id = getattr(user, current_app.login_manager.id_attribute)()
    session['_user_id'] = user_id  # This is what we need
    session['_fresh'] = fresh
    session['_id'] = current_app.login_manager._session_identifier_generator()

Thus the use of sess['_user_id'] = email in our decorator. If we were to use a different approach, such as a custom implementation or a different extension, we would have to adapt our decorator accordingly. Remember, we are not interested in where the user info is coming from. We just want to move our flask app to an authenticated state and do some assertions based on that state.

With the above decorator we can make changes to our second test:

@force_login(email='test@gmail.com')
def test_index_page__logged_in(client):
    res = client.get('/')
    assert res.status_code == 200

Noice! Definitely, looks cleaner.

We have moved our login logic out of test into the force_login decorator so that we can focus on the test.

We can make use of the decorator package to cleanup our decorator:

@decorator
def force_login(func, email=None, *args, **kwargs):
    for arg in args:
        if isinstance(arg, FlaskClient):
            with arg:
                with arg.session_transaction() as sess:
                    sess['_user_id'] = email
            return func(*args, **kwargs)
    return func(*args, **kwargs)

Let's see if we can make our decorator a bit more generic. We can pull out the logic for modifying the session. Let's make the following changes:

def login_user(sess, email):
    sess['_user_id'] = email


@decorator
def force_login(func, cb=None, *args, **kwargs):
    for arg in args:
        if isinstance(arg, FlaskClient):
            with arg:
                with arg.session_transaction() as sess:
                    cb(sess)
            return func(*args, **kwargs)
    return func(*args, **kwargs)

Then we can change the decorator call as follows:

@force_login(cb=lambda s: login_user(s, 'test@gmail.com'))
def test_index_page__logged_in(client):
    res = client.get('/')
    assert res.status_code == 200

We are wrapping the function responsible for modifying the session in a lambda because we want to be able to change the email parameter per test.

The decorator approach isn't limited to authentication. We can use also use it for data insertions into a DB and other use cases I have no idea about 🤯 .

With the above approach, we gain two things:

Cleaner code - Our tests look cleaner since they do not have login logic.
Abstraction - Since we have moved all login logic to a decorator, we are able to use the decorator in multiple tests without worrying about the implementation details of authenticating a user.

Repo:
https://github.com/michaelbukachi/flask_auth_testing

Flask-Authlib-Client

Michael Bukachi — Tue, 31 Dec 2019 12:41:16 +0000

I present to you Flask-Authlib-Client, a flask extension for authlib that answers the question "How do I validate tokens from a different resource server?". I haven't managed to publish it on Pypi because I'm having issues with my pypi account. Hoping to get it sorted soon.

Check it out on Github.

Happy New Year!

Edit

Finally got my pypi account back (yeepie!). You can now install the extension with:

pip install Flask-Authlib-Client

Making Safe API Calls With Python

Michael Bukachi — Wed, 28 Aug 2019 18:23:04 +0000

Making REST API calls in python is quite common and easy especially due to existince of libraries such as requests.

Take the following example:

def get_user(user_id):
    res = requests.get(f'https://jsonplaceholder.typicode.com/users/{user_id}')
    if res.ok:
        return res.json()
    else:
        print(f'{res.status_code}: {res.text}')
        return {}

The code is pretty straightforward. We are defining a function to fetch a user's details from an API (A very handy web app for testing out web apps).

Simple. Right?

However, what happens when there is no connectivity? Exceptions are raised.
This can easily be wrapped in a try...except clause but it makes our code messy, especially when we have multiple endpoints to call.

Enter returns.

Returns is a library written with safety in mind. It's quite powerful and has a lot to offer. Now let's quickly fix our unsafe code.

class GetUser(object):

    @pipeline
    def __call__(self, user_id: int) -> Result[dict, Exception]:
        res = self._make_request(user_id).unwrap()
        return self._parse_json(res)

    @safe
    def _make_request(self, user_id: int) -> requests.Response:
        res = requests.get(f'https://jsonplaceholder.typicode.com/users/{user_id}')
        res.raise_for_status()
        return res

    @safe
    def _parse_json(self, res: requests.Response) -> dict:
        user = res.json()
        return user


get_user = GetUser()

We have defined a class which can be invoked as a function once instantiated. We need to take note of the @safe decorator, a very handy decorator which wraps any exception raised into a Failure object.
The Failureclass is a subclass of the Result type which is basically a simple container.
Now, our code changes from:

try:
    user = get_user(1)
except Exception:
    print('An error occurred')

to:

user = get_user(1) # returns Success(dict) or Failure(Exception)
user = user.value_or({})

Isn't that just elegant?

I know what you are thinking. It's too much code!
That's the same thing I thought at first. But after playing around with the library and a bit of customization, I started to notice that my code looked cleaner. I could quickly scan through a file and get the gist of what is going without have to follow references. This is just the surface. Returns has way more to offer. Check it out.

Here's a decorator I came up with to automatically unwrap Result inner values or provide a default value instead:

def unwrap(success=None, failure=None):
    def outer_wrapper(func):
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            result = func(*args, **kwargs)
            if is_successful(result):
                if success is not None:
                    return success
            else:
                if failure is not None:
                    return failure
            return result._inner_value

        return wrapper

    return outer_wrapper

Usage:

    @unwrap(failure={}) # If a failure occurs an empty dict is returnd
    @pipeline
    def __call__(self, user_id: int) -> Result[dict, Exception]:
        ...

user = get_user(1) # returns dict or empty dict

Cheers!

A Flask Anti-Js Movement

Michael Bukachi — Fri, 02 Aug 2019 20:15:11 +0000

For the past couple of months I have been developing APIs using Flask. During this time, I noticed one thing in common. API consumers (at least the ones I've worked with) never fully go through the documentation provided to familiarize themselves with what is needed. Now, I'm not sure whether this is intentional or accidental (need feedback 😄).
The results of trial and error by developers consuming your API can be quite annoying especially if you have setup error-reporting services like sentry.

Imagine waking up to a tonne of emails from your error-reporting service only to find out that it's a result of bad input😥. Using Flask extensions such as Flask-Restplus can help you manage bad input easily. Also, Bad Requests exceptions can easily be ignored on error-reporting services so that they don't trigger alerts all the time. However, there are path variables which introduce a different kind of problem.
Take a look at the following snippet:

@app.route('/<string:user_id>')
def get_details(user_id):
.... # Do something with user_id

You have created an endpoint which fetches users details from a database somewhere and returns the necessary details. You have provided proper documentation about usage of that endpoint and you are quite satisfied with your work. You decide to go for an early lunch break only to come back quite early due to the fact that you started receiving error alerts as soon as you were about to have your lunch😩.

You quickly check the logs and stacktraces to see what is going on.
All the errors are coming from your newly created endpoint.

How?

You are pretty sure you added all the necessary checks. You even added a type check to the path variable to prevent invalid types.

On looking closer at the stack traces, you notice that the user_id passed was a value of undefined. The developer consuming your API was probably in the dreaded trial and error phase, trying to wire things up on the frontend.

Now, a good API is supposed to be protected from misuse. And yes, this includes trial and error actions by devs consuming your API.

To deal with "undefined" variables you could probably add a conditional check and return an appropriate response.

@app.route('/<string:user_id>')
def get_details(user_id):
    if user_id == 'undefined':
        raise BadRequest('Invalid user id')
    # Do something with user_id
....

However, this solution does not scale well. What if you have hundreds of endpoints with path variables? What then?

A better solution would be to make use of Flask's before_request decorator like so:

@app.before_request
def check_undefined_values():
    for variable in request.view_args.values():
        if variable == 'undefined':
            raise BadRequest('\'undefined\' value found.')

This approach works best since the check_undefined_values function is always called before a request is forwarded to you endpoint.

I have created a Flask extension called Flask-AntiJs that uses the above. It has extra functionalities such as the ability to check for undefined values in request payloads and query parameters. It's actually my first Flask extension so check it out😁.

That's all for today.

Flask Vue.js Integration Tutorial

Michael Bukachi — Fri, 24 May 2019 19:59:56 +0000

This tutorial answers the question, "How do I integrate Vue.js with Flask?" Since you are reading this tutorial, I assume that you know that Flask is a Python microframework built for rapid web development. If you are not familiar with flask or probably think that I am going to talk about a thermos 😜, then I suggest reading about it here before proceeding with this tutorial.

Vue.js is a progressive framework for building user interfaces. If you are not familiar with it, you can read about it here.

Now that you are familiar with both Flask and Vue.js, we can begin.

Flask Setup

Let's install a couple of dependencies first:



pip install --user cookiecutter

Cookiecutter is an awesome command-line utility for quickly bootstraping project templates. We are using cookiecutter so that we don't spend too much time setting up the project. Remember, flask is not batteries included like Django, so quite a bit of work has to be put into the initial setup of a project.

Now that you have installed Cookiecutter, we need grab a project template. For this tutorial, we just need a simple flask API. Run the following commands:



cookiecutter gh:mobidevke/cookiecutter-flask-api-starter

You should get the following output:



repo_name [api-starter]: flask-vuejs-tutorial
api_name [Api]: api
version [1.0.0]: 1.0.0

A folder called flask-vuejs-tutorial should be created. Navigate into that folder and you should see the following structure:



├── app
│   ├── config.py
│   ├── factory.py
│   ├── __init__.py
│   ├── models
│   │   ├── base.py
│   │   ├── database.py
│   │   ├── datastore.py
│   │   └── __init__.py
│   ├── resources
│   │   ├── example.py
│   │   └── __init__.py
│   └── utils.py
├── pytest.ini
├── README.md
├── requirements.txt
├── settings.py
├── tests
│   ├── conftest.py
│   ├── __init__.py
│   ├── test_app.py
│   ├── test_models.py
│   ├── test_resources.py
│   └── utils.py
├── unit-tests.sh
└── wsgi.py

Beautiful, isn't it 😃?

Before we proceed we need to setup a virtual environment. Run:



python -m venv venv

You can now open the project folder using your favourite IDE/Text Editor. Remember to activate the virtual environment before proceeding to the next step.
Now we can install our dependencies. Run:



pip install -r requirements.txt

Once done open app/config.py. You'll notice that this API template uses a postgres database connection. You can setup a postgres db with the necessary credentials, if you don't mind. Otherwise, replace the contents of that folder with the following lines of code:



import os


class Config:
    ERROR_404_HELP = False

    SECRET_KEY = os.getenv('APP_SECRET', 'secret key')

    SQLALCHEMY_DATABASE_URI = 'sqlite:///tutorial.db'
    SQLALCHEMY_TRACK_MODIFICATIONS = False

    DOC_USERNAME = 'api'
    DOC_PASSWORD = 'password'


class DevConfig(Config):
    DEBUG = True


class TestConfig(Config):
    SQLALCHEMY_DATABASE_URI = 'sqlite://'
    TESTING = True
    DEBUG = True


class ProdConfig(Config):
    DEBUG = False


config = {
    'development': DevConfig,
    'testing': TestConfig,
    'production': ProdConfig
}

We have removed all postgres configurations in favour of sqlite ones. If you want to use postgres, leave the conf.py file untouched.
We now need to export our flask application. Run:



export FLASK_APP=wsgi:app

Now that we have finished setting up our flask API, run:



flask run

then open http://127.0.0.1:5000/example. You should see the following:



{"message": "Success"}

Vue.js setup

Now that our API is ready, we can proceed to bootstrap the vue application.
The first thing we need to do is install the vue cli. Run:



npm install -g @vue/cli
# OR
yarn global add @vue/cli

Once the installation finishes, you can check that you have the right version (3.x) with this command:



vue --version

At the root of your project folder run:



vue create web

I chose default (babel, eslint) as the preset and yarn as my package manager. If you are familiar with node projects you can go ahead and choose your preferred options. If not, just follow the defaults for this tutorial.
Now navigate into the new clearly created web folder and run:



yarn serve
# OR
npm run serve

If you navigate to http://localhost:8080/, you should see a Welcome to Your Vue.js App text.

Now we are ready to start the integrations.

In the web folder, create a file called vue.config.js and paste the following contents:



const path = require('path');

module.exports = {
  assetsDir: '../static',
  baseUrl: '',
  publicPath: undefined,
  outputDir: path.resolve(__dirname, '../app/templates'),
  runtimeCompiler: undefined,
  productionSourceMap: undefined,
  parallel: undefined,
  css: undefined
};

Note If you are using Vue CLI 3.3 and above use publicPath instead of baseUrl.
Here, are defining some configurations for the vue cli.
We are only interested in three fields: assetsDir, baseUrl, outputDir.
Let's start with the outputDir.
This folder holds the location of the built vue files, that is, the folder that will hold the index.html that wil load the vue app. If you observe the path provided, you'll notice that the folder is inside the app module of the flask application.
The assetsDir holds the folder for the static files (css, js etc). Note It is relative to the value provided in the outputDir field.
Finally, the baseUrl field will hold the path prefix for the static files in the index.html. You can check this to find out more information about other configuration options.
Now run:



yarn build
# OR
npm run build

If you open the app folder, you will notice that two new folders have been created, templates and static. They contain the built vue files.
Now create a views.py file in the app folder and paste the following contents:



from flask import Blueprint, render_template, abort
from jinja2 import TemplateNotFound

sample_page = Blueprint('sample_page', 'sample_page', template_folder='templates')


@sample_page.route('/sample')
def get_sample():
    try:
        return render_template('index.html')
    except TemplateNotFound:
        abort(404)

Now, what's going on here?
Well, we are creating a flask blueprint named sample_page and adding a route to it. This route will render our vue app.

Open __init__.py and add the following lines below app = f.flask:



.....
app = f.flask
from .views import sample_page

app.register_blueprint(sample_page, url_prefix='/views')

Here, we are registering the blueprint we created earlier.
We are giving the blueprint a url prefix so that our vue app is accessible from /views/sample.

The moment of truth has arrived.

Open http://127.0.0.1:5000/views/sample you should see the following:

If you check the logs, you will see the built resources were loaded correctly:



 * Serving Flask app "wsgi:app"
 * Environment: production
   WARNING: Do not use the development server in a production environment.
   Use a production WSGI server instead.
 * Debug mode: off
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
127.0.0.1 - - [24/May/2019 20:45:02] "GET /views/sample HTTP/1.1" 200 -
127.0.0.1 - - [24/May/2019 20:45:02] "GET /static/css/app.e2713bb0.css HTTP/1.1" 200 -
127.0.0.1 - - [24/May/2019 20:45:02] "GET /static/js/chunk-vendors.b10d6c99.js HTTP/1.1" 200 -
127.0.0.1 - - [24/May/2019 20:45:02] "GET /static/js/app.c249faaa.js HTTP/1.1" 200 -
127.0.0.1 - - [24/May/2019 20:45:02] "GET /static/img/logo.82b9c7a5.png HTTP/1.1" 200 -
127.0.0.1 - - [24/May/2019 20:45:02] "GET /views/favicon.ico HTTP/1.1" 404 -

You have successfully integrated Flask with Vuejs 😄.

The source code for this tutorial can be found here.