- 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>
