- This allows overriding these headers in individual pages easily instead of
relaxing global policy.
- Drop the obsolete CSP directive "block-all-mixed-content" and avoid a console
warning in Firefox.
Tests:
- Load a page and notice in the browser developer tools that the three headers
referrer-policy, content-security-policy, and x-content-type-options are set as
before.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Show a different message for them.
Test:
- Try to visit page like /plinth/apps/sharing/foo/edit/ where a share named
'foo' does not exist. The common error handling middleware is triggered and an
alert message 'Page not found' with exception trace back is shown.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- These could happen when a user tries to reload a page that only allows POST
requests.
- Or when the generic exception handling logic in the middleware redirects the
user to a page that only allows POST.
Tests:
- Insert a exception in the diagnose() of the 'users' app. Without the patch,
running diagnostics on the users app leads to a blank page. With the patch, the
user is redirected to Diagnostics app page and the original error is shown as a
alert message.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- In addition to the OperationalError, also handle all generic exceptions during
page submit and page load. Redirect to the same page or parent using
breadcrumbs.
- Log exceptions handled by common error middleware so that they are also part
of the system logs.
- Update kiwix test as needed.
- Refactor some test code that is setting up the menu items.
Tests:
- When an error occurs during form POST, the same page is show but with an error
message.
- When an error occurs in an app page during GET, the browser is redirected to
the parent section.
- When an error occurs in apps page during GET, the browser is redirected to the
home page.
- When an error occurs in home page during GET, the error is not handled and
default 500 handle is triggered.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Tests:
- Change locale to Spanish. Raise an exception in bepasty.privileged.setup().
Try to install bepasty. Without the patch, error is not translated. With the
patch, it is.
- Successful installation of an app shows translated success message.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Tests:
- Insert an exception in privileged setup() and uninstall() method and try to
install/uninstall app and notice that error messages are shown in a simple
format and extra details are provided, collapsed by default.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- During database error such as 'database is locked', show a special message
asking users to try again instead of submitting a bug report.
[sunil: Minor formatting, rename the template file name]
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
[jvalleroy: Fix missing import]
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
- Task of managing an operation's progress is now performed by the new Operation
class. Drop them from setup helper.
- Task of providing install() method is now moved to package module. Instead of
storing operation specific data in setup_helper like objects, store them in
thread specific storage that can retrieved anywhere during the operation without
holding references.
- Progress of an operation show as a progress bar is currently missing. This
will be regression until fixed later.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
This is an improvement over !2069, which solved #2094.
Tests:
- Install an app. Success result is shown.
- Install an app and kill the apt-get process in the middle. Error result is
shown.
- Click install on an app (email_server). Close the window without seeing the
result. Access the app page (like email_server/my_aliases) as a non-admin user.
No success/file message is shown. The page is shown properly. Access the page as
admin, success message is shown.
- Access an uninstalled/installed app page as anonymous user. User is redirected
to login page.
- Access an uninstalled/installed app page as non-admin user. Forbidden page is
shown.
- Access an uninstalled app page meant for non-admin users (such as
email_server/my_aliases) as non-admin user. Forbidden page is shown.
- Access an installed app page as admin. Success.
- Access an installed app page meant for non-admin users (such as
email_server/my_aliases) as admin. Success.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Fioddor Superconcentrado <fioddor@gmail.com>
- ugettext functions will be removed in Django 4.0. Each use emits a warning
when running with Django 3.2. Since we have warnings enabled in developer mode,
we see quite a few messages because of this.
- ugettext is already a simple alias of gettext. So, no regressions are
expected.
Tests:
- Accessing an affected app in UI with Django 3.2 and Django 2.2 works fine.
- Using Django 3.2 there are no warnings related to removal of ugettext
functions.
- Ran regular unit tests.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
A new function called `user_group_view` has been added to
restrict access to only users in the groups "vpn" and "admin".
Some changes are made in AdminRequiredMiddleware to handle this.
Signed-off-by: Joseph Nuthalapati <njoseph@riseup.net>
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>
- Only admins can now edit the groups of any user
- Only admins can mark any user as active or not
- Refactored all occurrences of admin checks to its own utility function
- 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.
Don't try to show setup view for login page. This happens under a rare
circumstance that user does not usually face. If 'users' module has not
been setup but we try to run first boot and last part of the firstboot
process is not yet completed and when user is not already logged in, an
infinite redirect happens.
Simply don't try to show setup view for login URL under any
circumstance. This is similar to how firstboot middleware itself does
not meddle with login URL.
Anonymous users were able to access pages that used
the 'public' decorator of stronghold. If such a page
showed the installation routine of the setup module
they were able to access and use it, in other words:
Anonymous users were able to install software.
Don't raise a 404 exception when a page is not found. Instead, simply
bypass the setup middleware so that other middleware have a chance to
process further.
Slight modification so that resolve method can be mocked during
unittests.
Django runs process_request() on all the middleware classes in order.
Then it runs process_view() on all of them again. During the runs, if
any of the views return a HttpResponse. Further processing is ignored.
Setup middleware was handling process_request() and returning
HttpResponse if the application as not setup. However, stronghold
middleware handles process_view(). Since process_request happens first
and response is being returned there, stronghold middleware is never
called.
Make setup middleware use process_view() instead.
