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
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.
user_modelis None, there’s no authentication and request.user is always an
user_modelcan be either
'auth.User'(the latter is not tested).
user_model is set, we have two
remote_user_headercontains some value, your application will be using HTTP authentication
remote_user_headeris None, your application uses 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:
ldap_auth_serveris None, Lino uses the passwords stored in its own database.
ldap_auth_serveris not None, Lino authenticates against the specified LDAP server.
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
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.