FLASK-PRINCIPAL(1)

📦 version 0.5.0, in arch rolling

🎀 NAME 🎀

okay so this is the manual page for flask-principal, aka FLASK-PRINCIPAL(1) — and the official one-liner is literally flask-principal - Flask-Principal Documentation. The page also opens with the iconic quote "I am that I am" and honestly? main character energy. 💅

🌈 INTRODUCTION 🌈

Flask-Principal gives you a very loose framework to tie in providers of two types of service, often located in different parts of a web application:

  1. Authentication providers
  2. User information providers

For example, an authentication provider may be oauth, using Flask-OAuth and the user information may be stored in a relational database. Looseness of the framework is provided by using signals as the interface. 🦋

The major components are the Identity, Needs, Permission, and the IdentityContext.

  1. The Identity — represents the user, and is stored/loaded from various locations (eg session) for each request. The Identity is the user's avatar to the system. It contains the access rights that the user has.
  2. A Need — is the smallest grain of access control, and represents a specific parameter for the situation. For example "has the admin role", "can edit blog posts".

Needs are any tuple, or probably could be object you like, but a tuple fits perfectly. The predesigned Need types (for saving your typing) are either pairs of (method, value) where method is used to specify common things such as "role", "user", etc. And the value is the value. An example of such is ('role', 'admin'). Which would be a Need for an admin role. Or Triples for use-cases such as "The permission to edit a particular instance of an object or row", which might be represented as the triple ('article', 'edit', 46), where 46 is the key/ID for that row/object.

Essentially, how and what Needs are is very much down to the user, and is designed loosely so that any effect can be achieved by using custom instances as Needs.

Whilst a Need is a permission to access a resource, an Identity should provide a set of Needs that it has access to. 🫶

  1. A Permission — is a set of requirements, any of which should be present for access to a resource.
  2. An IdentityContext — is the context of a certain identity against a certain Permission. It can be used as a context manager, or a decorator. ✨

The original page literally has this little [graph].SH LINKS bit sitting here — keeping that detail, bestie. The links are:

💖 PROTECTING ACCESS TO RESOURCES 💖

For users of Flask-Principal (not authentication providers), access restriction is easy to define as both a decorator and a context manager. A simple quickstart example is presented with commenting:

from flask import Flask, Response
from flask_principal import Principal, Permission, RoleNeed

app = Flask(__name__)

# load the extension
principals = Principal(app)

# Create a permission with a single Need, in this case a RoleNeed.
admin_permission = Permission(RoleNeed('admin'))

# protect a view with a principal for that need
@app.route('/admin')
@admin_permission.require()
def do_admin_index():
    return Response('Only if you are an admin')

# this time protect with a context manager
@app.route('/articles')
def do_articles():
    with admin_permission.require():
        return Response('Only if you are admin')

🔥 AUTHENTICATION PROVIDERS 🔥

Authentication providers should use the identity-changed signal to indicate that a request has been authenticated. For example, the following code is a hypothetical example of how one might combine the popular Flask-Login <https://flask-login.readthedocs.io/> extension with Flask-Principal:

from flask import Flask, current_app, request, session, \
        render_template, redirect
from flask_login import LoginManager, login_user, logout_user, \
        login_required
from wtforms import StringField, PasswordField
from flask_wtf import FlaskForm
from flask_principal import Principal, Identity, AnonymousIdentity, \
        identity_changed

app = Flask(__name__)
app.config['SECRET_KEY'] = 'notsosecret'

Principal(app)

login_manager = LoginManager(app)

class User:
    def __init__(self, id='1', email=None, password=None):
        self.id = id
        self.email = email
        self.password = 'abcd'
        self.is_authenticated = False
        self.is_active = True
        self.is_anonymous = True

    def get_id(self):
        return self.id
class DB:

    def __init__(self):
        pass

    def find_user(self, id=None, email=None):
        example_user = User(id=id, email=email)
        return example_user

@login_manager.user_loader
def load_user(userid):
    # Return an instance of the User model
    datastore = DB()
    return datastore.find_user(id=userid)

class LoginForm(FlaskForm):
    email = StringField('email')
    password = PasswordField('password')

@app.route('/login', methods=['GET', 'POST'])
def login():
    # A hypothetical login form that uses Flask-WTF
    form = LoginForm()

    if request.method == 'POST':

        # Validate form input
        if form.validate_on_submit():
            # Retrieve the user from the hypothetical datastore
            datastore = DB()
            user = datastore.find_user(email=form.email.data)

            # Compare passwords (use password hashing production)
            if form.password.data == user.password:
                # Keep the user info in the session using Flask-Login
                login_user(user)

                # Tell Flask-Principal the identity changed
                identity_changed.send(current_app._get_current_object(),
                                        identity=Identity(user.id))
                print('logged in ')
                return redirect(request.args.get('next') or '/')

    return render_template('login.html', form=form)

@app.route('/logout')
@login_required
def logout():
    # Remove the user information from the session
    logout_user()

    # Remove session keys set by Flask-Principal
    for key in ('identity.name', 'identity.auth_type'):
        session.pop(key, None)

    # Tell Flask-Principal the user is anonymous
    identity_changed.send(current_app._get_current_object(),
                            identity=AnonymousIdentity())

    return redirect(request.args.get('next') or '/')

@app.route('/')
def home():
    return 'home page'
if __name__ == '__main__':
    app.run(debug=True)

The login page snippet looks like this:

<html>

       <body>

              <form method="POST" action="/login">
                     {{ form.csrf_token }} {{ form.email.label }} {{
                     form.email }}<br> {{ form.csrf_token }} {{
                     form.password.label }} {{ form.password }}<br>
                     <input type="submit" value="Go">

              </form>

       </body>

</html>

🌸 USER INFORMATION PROVIDERS 🌸

User information providers should connect to the identity-loaded signal to add any additional information to the Identity instance such as roles. The following is another hypothetical example using Flask-Login and could be combined with the previous example. It shows how one might use a role based permission scheme:

from flask_login import current_user
from flask_principal import identity_loaded, RoleNeed, UserNeed

@identity_loaded.connect_via(app)
def on_identity_loaded(sender, identity):
    # Set the identity user object
    identity.user = current_user

    # Add the UserNeed to the identity
    if hasattr(current_user, 'id'):
        identity.provides.add(UserNeed(current_user.id))

    # Assuming the User model has a list of roles, update the
    # identity with the roles that the user provides
    if hasattr(current_user, 'roles'):
        for role in current_user.roles:
            identity.provides.add(RoleNeed(role.name))

👑 GRANULAR RESOURCE PROTECTION 👑

Now lets say, for example, you only want the author of a blog post to be able to edit said article. This can be achieved by creating the necessary Need and Permission objects, and adding more logic into the identity_loaded signal handler. For example:

from collections import namedtuple
from functools import partial

from flask_login import current_user
from flask_principal import identity_loaded, Permission, RoleNeed, \
     UserNeed

BlogPostNeed = namedtuple('blog_post', ['method', 'value'])
EditBlogPostNeed = partial(BlogPostNeed, 'edit')

class EditBlogPostPermission(Permission):
    def __init__(self, post_id):
        need = EditBlogPostNeed(unicode(post_id))
        super(EditBlogPostPermission, self).__init__(need)

@identity_loaded.connect_via(app)
def on_identity_loaded(sender, identity):
    # Set the identity user object
    identity.user = current_user

    # Add the UserNeed to the identity
    if hasattr(current_user, 'id'):
        identity.provides.add(UserNeed(current_user.id))

    # Assuming the User model has a list of roles, update the
    # identity with the roles that the user provides
    if hasattr(current_user, 'roles'):
        for role in current_user.roles:
            identity.provides.add(RoleNeed(role.name))

    # Assuming the User model has a list of posts the user
    # has authored, add the needs to the identity
    if hasattr(current_user, 'posts'):
        for post in current_user.posts:
            identity.provides.add(EditBlogPostNeed(unicode(post.id)))

The next step will be to protect the endpoint that allows a user to edit an article. This is done by creating a permission object on the fly using the ID of the resource, in this case the blog post:

@app.route('/posts/<post_id>', methods=['PUT', 'PATCH'])
def edit_post(post_id):
    permission = EditBlogPostPermission(post_id)

    if permission.can():
        # Save the edits ...
        return render_template('edit_post.html')

    abort(403)  # HTTP Forbidden

💫 COMBINING PERMISSIONS 💫

Okay so like — the core constructs are already enough for the cute simple use cases, no notes. But bestie, when things get complicated, you can literally combine existing permissions with bitwise operators and get a brand-new permission object that does the messy validation for you. It's giving "math but make it fashion". 💅

For example, you can absolutely build a permission where the identity has both the "blog_poster" or "blog_reviewer" role, but not the "under_probation" role. Like so:

blog_admin = Permission(RoleNeed('blog_admin'))
blog_poster = Permission(RoleNeed('blog_poster'))
blog_reviewer = Permission(RoleNeed('blog_reviewer'))
under_probation = Permission(RoleNeed('under_probation'))

prize_permission = ((blog_poster | blog_reviewer) & ~under_probation)

@app.route('/blog/prizes')
@prize_permission.require()
def prize_redeem():
    # find out what prizes are available to blog users that are not
    # under probation
    return render_template('prize_redeem.html')

You can chain literally any number of these together 🎀 — but you can also skip the operators and use the constructor classes directly to combine stuff:

from flask.ext.principal import AndPermission, OrPermission

allperms = AndPermission(blog_poster, blog_reviewer, blog_admin)
anyperms = OrPermission(blog_poster, blog_reviewer, blog_admin)

🦋 CUSTOM PERMISSIONS 🦋

Sometimes your permissions are gonna be decided by other circumstances that are, like, specific to whatever you need to implement. No cap, that's a whole mood. So for those you make custom classes to address your needs, like this:

from flask.ext.principal import BasePermission

class CustomPermission(BasePermission):
    def allows(self, identity):
        # Implement other conditions that allow this to pass
        return False

And these custom permissions can be combined together via the bitwise operators, exactly as explained above. Chain away, queen. 👑

🌸 STARTING THE EXTENSION 🌸

(this heading exists and that's literally all it is — no body text under it, iykyk 🙈)

🌈 MAIN TYPES 🌈

(also just a heading hanging out on its own, no content, we love a minimalist icon ✨)

⭐ PREDEFINED NEED TYPES ⭐

(another heading with nothing under it — yes babe, this is the whole section 💀)

💜 SIGNALS 💜

  • identity_changed — the signal that gets sent when the identity for a request has been changed. Something moved, and this is the announcement. 📣
  • identity_loaded — the signal that gets sent when the identity has been initialised for a request. The "she's here and she's ready" moment. 🫶

🎀 FLASK-PRINCIPAL CHANGELOG 🎀

Here's the full list of changes between each Flask-Principal release — the whole glow-up timeline, no skips. 💖

🗓️ Released 2026-05-31

🗓️ Version 0.4.0

Released June 14th 2013

  • Added Python 3 support
  • Dropped support for Python 2.5

🗓️ Version 0.3.5

Released April 3rd 2013

  • Fixed possible bug with AnonymousIdentity supplying "anon" as the username
  • Changed Indentity name property to id to be more generic

🗓️ Version 0.3.4

Released February 1st 2013

  • Add __repr__ method to Identity and Permission classes
  • Optimized _is_static_resource method

🗓️ Version 0.3.3

Released September 4th 2012

  • Add init_app method to accomodate usage with a factory pattern.

🗓️ Version 0.3.2

Released August 25th 2012

  • Update to check for static_url_path in Flask 0.9

🗓️ Version 0.3.1

Released August 16th 2012

  • Fixed bug with re-raising exceptions/tracebacks

🗓️ Version 0.3

Released June 20th 2012

  • Python 2.5/GAE support
  • New extension structure
  • Added ignore_static option
  • Updated docs

🗓️ Version 0.2

Initial development by Ali Asfshar. Original repository https://bitbucket.org/aafshar/flask-principal-main

  • Index <>
  • Module Index <>
  • Search Page <>

👑 Author 👑

Matt Wright

2012, Ali Afshar

And that's the whole page bestie, you ate that reading thing fr fr 🍓✨ this little beauty is FLASK-PRINCIPAL(1), version 0.3.5, stamped Sep 10, 2026 — go forth and permission responsibly, mwah 💋🦋

📦 where this page comes from