- When a template page is updated, we are having to restart service in order for
the new changes to reflect. This is due to caching of template files starting
Django 4.1[1]. Disable this behavior in development mode to allow reload the
browser page to see changes reflected.
Links:
https://docs.djangoproject.com/en/5.0/releases/4.1/#templates
Tests:
- Change a template file and reload the page without restarting service. The
changes should reflect immediately.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- Add explicit dependency on django-ipware >=3. django-axes >= 6 adds
only and optional dependency on django-ipware. Adding explicit dependency make
the behavior safer.
- Depend on django-axes >= 5 where the authentication backend and other features
are available. The new code won't work with older versions. The new approach
uses and authentication backend to deny access to the login form on lockout and
a middleware to redirect user to locked out form when limit of attempts have
been reached.
- Drop old code used for compatibility with django-axes 3.x.
- Suppress verbose and debug messages as django-axes is too chatty.
- Re-implment the CAPTCHA form entirely. In the old style, we have a login form
with CAPTCHA field. That would not work with the new django-axes authentication
middle. On submission of the form, auth.authenticate() will be called. This
call invokes various authentication backends include django-axes authentication
backend. This backend's behavior is to reject all authentication attempts when
the IP is listed in locked table. The new approach is to provide a simple
CAPTCHA form with just the CAPTCHA field. If the form is successfully
validated (correct CAPTCHA is provided), then the lock on the IP address is
reset. The user is then free to perform 3 more attempts to login.
- Update firstboot form to send the request parameter when using
auth.authenticate() method. This needed by Django axes' authentication method
which will be triggered.
Tests:
- Run tests on Debian Bookworm and Debian testing.
- Axes verbose messages and debug messages are not printed on the console when
running FreedomBox in debug mode.
- Only three invalid attempts are allowed at the login page. After the final
incorrect attempt, user is redirected to CAPTCHA page. Visiting the login page
using the URL works but entering the correct credentials still takes the user to
CAPTCHA page.
- CAPTCHA form appears as expected. Clicking the CAPTCHA images downloads the
audio file corresponding to the image. Incorrect CAPTCHA shows an error. Correct
CAPTCHA takes the user to login form where they are able to login with correct
credentials. Entering incorrect credentials 3 times will take the user again to
CAPTCHA page.
- Creating user account during firstboot works.
- Blocked IP address the IP of the client such as 10.42.0.1 and not the local IP
address 127.0.0.1 according the django-axes log messages. While one client IP
address is blocked, another IP is able to login to the same user account that
was attempted by the blocked client.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Avoid any potential problems with sqlite3 not being present.
- Avoid any potential problems with secret key not being available. Avoid
accidentally creating the secret key hardware/container images.
Tests:
- --list-dependencies works with and without secret key and plinth sqlite3.
- --list-dependencies works with plinth and root users.
- --list-dependencies does not create the sqlite3 database or the secret key.
- Running app works in normal mode and creates the secret key.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Drop message for initialization of each app. This was removed earlier but was
reintroduced during init() refactoring. There is not much use for these messages
and the noise they generate hide some important messages relating to domains
added.
- Print lists in a better way for humans.
- Add a log message after all the initialization is completed.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
This allows --list-dependencies to run without having to write to disk.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
A simple Django configuration does not need to create the database whereas DB
migration requires creating the database.
In some operations such as listing dependencies, we can skip running the second
part and so writing to database will no longer be necessary during such
operations.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
During provisioning of container/VM, we need to run --list-dependencies. When
run without --develop, they are unable to create database. When run with
--develop, the output from the database migration process is messing up the
output meant for stdin as it is outputting to stdout instead stderr. Reduce
verbosity even in debug mode to fix this.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Currently, sessions are created as files in /var/lib/plinth/sessions. If a user
does not logout, the sessions remains there ever after expiry. Cleanup these
accumulating files by running a cleanup job every week.
Adding django.contrib.sessions to apps list necessary to ensure that
'clearsessions' management command is available. This creates an empty database
table for session storage but is harmless.
Tests performed:
- When run with the change for first time, migration is run for
django.contrib.sessions app.
- Change the scheduled interval to 30 seconds in the code. Login as a user. A
new session file is created in data/var/lib/plinth/sessions. Forward the system
clock by at least 2 weeks. The session expires. Within 30 seconds the file is
also removed.
- Login, then remove the django-secret.key. In 30 seconds we see a message that
the session data is corrupt. Advance the clock by at least 2 weeks. The session
file is removed and the message about session data is no longer printed.
- Repeat for system level plinth after `./setup.py install` and `sudo -u plinth
plinth`.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Secret is important for various functions of Django. There is no impact on
existing installations due to the change. Improves the security of existing
functions in minor ways and will be useful in future usage of Django.
- Create the file in /var/lib/plinth/ with 0o600 permissions.
- Make git ignore the file in code folder.
- Don't copy the file during './setup.py install' operation.
Impact to users after upgrade:
- All existing sessions will get logged out. This is because SECRET_KEY is used
to generate user session hash that is used to logout users when their password
changes.
Tests performed:
- Run development version of service. File should get created in
data/var/lib/plinth/django-secret.key. Permissions should be 0o600.
- Run again, the file should not be overwritten. Printing
django.conf.settings.SECRET_KEY should match the one in the file.
- Run `setup.py install`. This should not install django-secret.key in
/var/lib/plinth.
- Run `sudo -u plinth plinth`. This should create the secret key file in
/var/lib/plinth/django-secret.key. Permissions on the file should be 0o600.
Ownership should be plinth:plinth.
- Remove the file in both cases, a fresh new file should get created with new key.
- Truncate the file to less than 128 chars, the existing file should get
overwritten with new key.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
This allows for many cases of having to deal with Django objects such as models.
- Allows all modules including ones with models to be imported by Sphinx.
- Run most of the management commands using django-admin.
- Make it simpler to import all modules on REPL interactive Python shells.
Does not change any of the settings that we are passing to Django for
configuration.
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
This is needed to ensure that all the time/date values stored in the database
are UTC. A timezone change in the settings should not make the database values
inconsistent.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Use the X-Forwarded-For header only if specified in the configuration. This
makes FreedomBox safe to use when not behind a reverse proxy server (although
we are unlikely to do this).
- When fetching the IP address to reset after successful login, use the
X-Forwarded-For header only if specified in the configuration.
- Minor flake8 refactorings.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Passwords will be automatically upgraded for each user on login.
Usernames not yet upgraded are vulnerable to user enumeration attack due to
difference in password check timing.
No need to add build dependency on python3-argon2 because tests use a different
Django configuration which does not use argon2 hash.
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Explicitly setup the list of Django languages. Keep them sorted by language
code.
- Fallback to language name when Django can't provide locale language name.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
