-
Notifications
You must be signed in to change notification settings - Fork 2
Port bootstrap improvements from lecture capture preferences webapp #36
base: master
Are you sure you want to change the base?
Conversation
To speed up tox environment builds, allow tox to make use of packages already installed in the container.
The auto-generated migrations are rarely flake8 friendly so ignore them.
Copy the logging configuration from other projects to ensure that exceptions are recorded in the logs.
For running in production, make sure that the production Raven certificate is specified.
Add in the standard security features for our web applications: * HTTP -> HTTPS automatic redirect. (Disabled in development and for tests.) * CORS headers * Clickjacking protection middleware
Add in the Django Debug Toolbar configuration for development.
Add in the Django REST Framework and associated packages which we use. configure the DRF to allow for session-based and token authentication. The token authentication is useful to allow for "service account" or "robot" users.
Add in auto-generated Swagger API documentation and, in development, a container which lets you browse it via Swagger UI.
Add in django-ucamlookup which is simpler to use than lookupproxy if we're deploying in-house. Since lookup required extra configuration to use from outside of the CUDN, we make it opt-in.
The README and documentation generated by the bootstrap included some incorrect references to the repository location and some out-of-date advice. Update them accordingly.
Having a default of "YES" breaks tests for the moment since tests are run outside of the CUDN.
I'm not quite sure why the tests are failing because they're in an unrelated area of the template. Will investigate. |
@@ -148,3 +151,27 @@ | |||
|
|||
#: Allow members who are not current members to log in? | |||
UCAMWEBAUTH_NOT_CURRENT = False | |||
|
|||
# Allow all origins to access API. | |||
CORS_URLS_REGEX = r'^/api/.*$' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated but found this while looking at CORS info in DRF: https://www.django-rest-framework.org/topics/ajax-csrf-cors/
Do we have CSRF protection enabled in DRF?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fact, we cannot trivially disable it just for the DRF since the "unsafe" method protection is provided by the CSRF protection middleware.
SECURE_REDIRECT_EXEMPT = ['^healthz/?$'] | ||
|
||
SECURE_SSL_REDIRECT = True | ||
SECURE_HSTS_SECONDS = 31536000 # == 1 year |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
HSTS doesn't accept self-signed certificates or non HTTP connections, making the website impossible possible to visit after the first installation (with a self-signed certificate while it tries to get the real one using let's encrypt) or if let's encrypt fails to renew. It's worth noting that and thinking about it before going to that route.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the same route we've gone down for the media platform and preferences webapp (And probably others.) If we're going for consistency, we should keep it. If we're unsure then we should remove it from where we've used it at the moment.
# TLS termination for us. In future this setting might need to be moved to settings.docker or to be | ||
# configured via an environment variable if we want to support a wider range of TLS terminating | ||
# load balancers. | ||
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this also needed when deploying to GCP or only internally using the UIS load balancer?
In any case it's a dangerous setting and we shouldn't leave it by default to be on, see django docs warning on this topic: https://docs.djangoproject.com/en/2.1/ref/settings/#secure-proxy-ssl-header
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need it with GCP too both for nginx and Google-provided Ingresses.
Fair point about dangerous by default. I'll put it behind an option like ucamwebauth.
'': { | ||
'handlers': ['console'], | ||
'propagate': True, | ||
'level': 'INFO' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This conf will be used for all environments (as it is in docker.py), hence I believe 'level' should be configurable via an env variable and put into the readme. We may not want to log INFO in production systems, for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, we need to port that to the preferences webapp then.
}, | ||
'loggers': { | ||
'': { | ||
'handlers': ['console'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd a 'email' handler for 'ERROR' level logs in production systems as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, we need to port that to the preferences webapp then.
djangorestframework | ||
django-cors-headers | ||
drf-yasg | ||
django-crispy-forms |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we using this at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As this is a cherry-pick of the preferences webapp PR, I suppose we should see if there was a subsequent commit in the preferences webapp which removed django-crispy-forms? AFAICT it's still in the current master.
schema_view = get_schema_view( | ||
openapi.Info( | ||
title='{{ cookiecutter.project_name }}', | ||
default_version='v1', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
v1Alpha by default until finished?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly. If so, we'd need to update the preferences webapp.
This PR uses a combination of
git format-patch
andgit am
to port the changes from uisautomation/lecture-capture-preferences-webapp#4 back into the bootstap application. As such the commit dates, authorship and description are as in the original PR with fixups as necessary to allow use in the template.A deviation from the mechanical conversion of the changes is to make ucamlookup an optional feature. For extra-CUDN deployments, additional work is needed to use ucamlookup and we may not actually need to in all cases.