And re-activate cfg.get_config_paths() for easier testing
Signed-off-by: Michael Pimmer <info@fonfon.at>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Newer versions of Django axes have newly way to get the IP address of a client
using ipware library. This has multiple security issues
https://github.com/jazzband/django-axes/issues/286 . Workaround them by
controlling the X-FORWARDED-FOR header sent from Apache to FreedomBox and by
limiting the headers that ipware uses.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
This is the final change required for Django 2.0 support. Instead of using
MIDDLEWARE_CLASSES use MIDDLEWARE setting. Support for new style middleware was
provided in version 0.3.0, so depend on that version. Django built-in middleware
already supports new style and plinth middleware will now support new style.
The actual semantics of the middleware don't need changes. See:
https://docs.djangoproject.com/en/2.0/topics/http/middleware/#upgrading-pre-django-1-10-style-middleware
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
(django-axes + django-simple-captcha) with sso is working at this point.
Signed-off-by: Joseph Nuthalpati <njoseph@thoughtworks.com>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- clearing ip address correctly is not implemented yet
- currently clearing all ip addresses
Signed-off-by: Joseph Nuthalpati <njoseph@thoughtworks.com>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
User will be shown captcha in the second attempt to login if login
fails in the first attempt.
Signed-off-by: Joseph Nuthalpati <njoseph@thoughtworks.com>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Added all default Django password validators.
Not enforcing special characters.
https://blog.codinghorror.com/password-rules-are-bullshit/
Signed-off-by: Joseph Nuthalpati <njoseph@thoughtworks.com>
Reviewed-by: Johannes Keyser <johanneskeyser@posteo.de>
- Essential modules would be installed by apt as they are already
dependencies of plinth.
- Plinth trying to trigger an installation is unnecessary.
- Plinth installing deb packages might also cause problems with plinth
startup if automatic upgrades are running.
- Added back the --setup option
- setup doesn't run when something else like diagnostics is invoked
Signed-off-by: Joseph Nuthalpati <njoseph@thoughtworks.com>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Capture all Python warnings so that they can shown as part of logging system
on console and in log file.
- Also capture deprecation warnings into logging system if debug mode is
enabled. Current versions of Python disable deprecation warnings by default.
Django 1.11 also follows this approach now.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Johannes Keyser <johanneskeyser@posteo.de>
- Removed key generation for mod_auth_pubtkt from first boot.
- Running setup every time plinth starts so that new essential modules
can be setup properly.
Partially fixes#875
- Remove apps and system modules and merge their views into main views.
- Move main_menu from cfg into menu.py.
- Remove dependencies of other modules on apps and system modules.
- Update tests.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
- Rename AdminMiddleware to AdminRequiredMiddleware to be consistent
with stronghold/Django terminology
- Simplify .gitignore pattern
- Format single line docstrings as per PEP8.
- Add missing docstrings.
- Restrict lines to 79 characters.
It is no longer very important to show Django configured applications
and module import messages because in practice we have rarely ever seen
being useful anywhere but for development. Just print the module load
order just once.
We pretty much only run in systemd environment and I don't see that
changing any time soon. By relying on it, we can reduce some burden.
Remove init script.
Daemonizing is not needed for systemd. Remove code related
daemonization.
- There is no reason to limit the number of languages supported by the
application. This is what happens when LANGUAGES is set during Django
configuration. Users should be able to set a language using browser
preferences and see at least the Django translated messages even if
Plinth messages are not translated (example user create/edit form).
- If we wish to limit the number of language options shown duing
language selection (for quality perception reasons), we should perform
the limiting at the time of configuration.
- Note that when a new language is requested in translation tool, we
create an empty file and that may lead to language being shown but
with few strings actually translated. This will have poor impact on
user experience. I wonder if we should filter language at all,
keeping this in mind.
- The --setup argument sets up all applications that declare themselves
as essential.
- This is done synchronously.
- Plinth exits after the setup is complete.
- Plinth fails with an error in case any of the setup tasks fail. The
process will be continued on next invocation or access of application
from UI.
- The last part of the module import path is the module name. This also
becomes the Django app name. Apps names have to be unique. Hence,
there is no scope for two different modules with same name but
different load path to exist in the project.
- Most uses of list of loaded modules are dealing with app names instead
of full module load path. This is due to the fact that Django deals
with app names and not module paths.
- It is also somewhat clumsy to access a loaded module as we are
re-importing every time to get access module.
- Simplify all of the above by using app names are module identifiers
and maintaing an ordered dictionary of app names to loadded modules.
- Remove unused imports.
- Minor styling fixes.
- Split the read method into two separate methods for getting the config
file and for reading config file.
- Use logging module for printing error.
- Fix global variable naming.
- Get/set/show the realpath of the config file.
- Convert config items into a list so that the order is more
predictable. This is the reason for unpredictable failures in test
cases.
