Lino defines some configuration settings for easily switching between different commonly-used authentication methods.

In other words, Lino automatically decides which authentication method to use and installs the required middleware depending on your file.

You may override these out-of-the-box methods by specifying the auth_middleware setting. If this is not empty, the logic described below does not apply.

  • If user_model is None, there's no authentication and request.user is always an AnonymousUser instance.

  • user_model is set automatically when lino.modlib.users is installed.

  • Otherwise, user_model can be either 'users.User' or 'auth.User' (the latter is not tested).

When user_model is set, we have two more possibilities:

Session-based authentication

This means that your application has "Login", "Logout" and "Register" buttons, and that django.contrib.sessions is added to your INSTALLED_APPS.

There are two variants of session-based authentication:

  • If ldap_auth_server is None, Lino uses the passwords stored in its own database.

  • If ldap_auth_server is not None, Lino authenticates against the specified LDAP server.

HTTP authentication

HTTP authentication means basically that Lino delegates the authentication to the web server.

This method suits best when there is already a central user management system (e.g. an LDAP server) running on a site and authentication granted by the web server.

Lino trusts completely the REMOTE_USER header (remote_user_header) of any incoming request. If there is no user with that username in Lino's database, Lino will silently create a User with minimum rights.

There is currently no system (yet) to automatically synchronize Lino's Users table from the LDAP server or whatever user database used by the web server.

One advantage of this is that Lino does not need any sessions.

See also