If you work on a project that uses database migrations with other developers, it is likely that you have experienced migration conflicts at some point. These occur when two or more developers are merging unrelated features to the master source control branch at around the same time, with each feature requiring different changes to the database.

In this article, I'm going to describe the problem and its solution in detail, using an actual example based on my Flask-Migrate extension. While I will be using commands that are specific to Flask-Migrate and Alembic, the solution to the problem that I present here can be adapted to other database migration frameworks.

The Flask response class, appropriately called Response, is rarely used directly by Flask applications. Instead, Flask uses it under the covers as a container for the response data returned by application route functions, plus some additional information needed to create an HTTP response.

What's not widely known, is that Flask gives applications the option to replace the stock response class with a custom one, opening the door to some neat tricks. In this article I'm going to show you how to take advantage of this technique to simplify your application code.

Some of you know that for the last few weeks I have been quietly but steadily working on a significant new release of Flask-SocketIO that will be labeled 1.0, and that is practically a complete rewrite. Given that this is a fairly popular extension, I would like to ask existing users to test it and provide feedback before it is officially released.

After I published my article on using Celery with Flask, several readers asked how this integration can be done when using a large Flask application organized around the application factory pattern. It's a very good question, as it is non-trivial to make Celery, which does not have a dedicated Flask extension, delay access to the application until the factory function is invoked.

In this article I'm going to describe in detail how I added Celery to Flasky, the application featured in my Flask book.

In this short blog post I want to share the two presentations I gave at PyCon 2015, which are now available to watch on YouTube.

In case you haven't heard, this year I will, once again, host a Flask class at PyCon in Montreal. The class is titled Flask Workshop, and is scheduled for Wednesday, April 8th from 9am to 12:20pm. For some reason not all the information I provided for this class has been published on the PyCon website, so in case you need some help deciding if this class is for you, I have all the details below.

In this article I'm going to introduce an authentication scheme known as two factor authentication. As the name implies, this method requires the user to provide two forms of identification: a regular password and a one-time token. This greatly increases account security, because a compromised password alone is not enough to gain access, an attacker also needs to have the token, which is different every time. You can see me do a short demonstration of this technique in the video above.

As usual, this article includes a complete example that implements this authentication technique in a Flask application. You may think this is going to be an advanced article that needs complex cryptographic techniques, specialized hardware and/or proprietary libraries, but in reality it requires none of the above. The solution is relatively simple to add if you already have username and password authentication in place, and can be done entirely with open standards and open-source software. There are even open-source token generation apps for your Android or iOS smartphone!

The topic of running background tasks is complex, and because of that there is a lot of confusion around it. I have tackled it in my Mega-Tutorial, later in my book, and then again in much more detail in my REST API training video. To keep things simple, in all the examples I have used so far I have executed background tasks in threads, but I always noted that for a more scalable and production ready solution a task queue such as Celery should be used instead.

My readers constantly ask me about Celery, and how a Flask application can use it, so today I am going to show you two examples that I hope will cover most application needs.

Many web sites offer users the option to use a streamlined single-click registration and login built on third party authentication services, typically run by the big social networks. In my Flask Mega-Tutorial I showed you how to use one of these protocols, called OpenID.

In this article I want to give you an introduction to the OAuth protocol, which these days has replaced OpenID as the preferred third party authentication mechanism. I will also show you a complete Flask application that implements "Sign In with Facebook" and "Sign In with Twitter" functionality. With these two implementations as a guide you should find it easy to add any other OAuth providers you may need.

I'm sure by now you know that I have released a book and a couple of videos on Flask in cooperation with O'Reilly Media. While the coverage of the Flask framework in these is fairly complete, there are a small number of features that for one reason or another did not get mentioned much, so I thought it would be a good idea to write articles about them here.

This article is dedicated to streaming, an interesting feature that gives Flask applications the ability to provide large responses efficiently partitioned in small chunks, potentially over a long period of time. To illustrate the topic I'm going to show you how to build a live video streaming server!