Configuration options¶
The PLOTLY_DASH
settings variable is used for configuring django-plotly-dash
. Default values are shown
below.
PLOTLY_DASH = {
# Route used for the message pipe websocket connection
"ws_route" : "dpd/ws/channel",
# Route used for direct http insertion of pipe messages
"http_route" : "dpd/views",
# Flag controlling existince of http poke endpoint
"http_poke_enabled" : True,
# Insert data for the demo when migrating
"insert_demo_migrations" : False,
# Timeout for caching of initial arguments in seconds
"cache_timeout_initial_arguments": 60,
# Name of view wrapping function
"view_decorator": None,
# Flag to control location of initial argument storage
"cache_arguments": True,
# Flag controlling local serving of assets
"serve_locally": False,
}
Defaults are inserted for missing values. It is also permissible to not have any PLOTLY_DASH
entry in
the Django settings file.
The Django staticfiles infrastructure is used to serve all local static files for the Dash apps. This requires adding a setting for the specification of additional static file finders
# Staticfiles finders for locating dash app assets and related files
STATICFILES_FINDERS = [
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
'django_plotly_dash.finders.DashAssetFinder',
'django_plotly_dash.finders.DashComponentFinder',
'django_plotly_dash.finders.DashAppDirectoryFinder',
]
and also providing a list of components used
# Plotly components containing static content that should
# be handled by the Django staticfiles infrastructure
PLOTLY_COMPONENTS = [
# Common components (ie within dash itself) are automatically added
# django-plotly-dash components
'dpd_components',
# static support if serving local assets
'dpd_static_support',
# Other components, as needed
'dash_bootstrap_components',
]
This list should be extended with any additional components that the applications
use, where the components have files that have to be served locally. The components that
are part of the core dash
package are automatically included and do not need to be
provided in this list.
Furthermore, middleware should be added for redirection of external assets from
underlying packages, such as dash-bootstrap-components
. With the standard
Django middleware, along with whitenoise
, the entry within the settings.py
file will look something like
# Standard Django middleware with the addition of both
# whitenoise and django_plotly_dash items
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'whitenoise.middleware.WhiteNoiseMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django_plotly_dash.middleware.BaseMiddleware',
'django_plotly_dash.middleware.ExternalRedirectionMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
]
Individual apps can set their serve_locally
flag. However, it is recommended to use
the equivalent global PLOTLY_DASH
setting to provide a common approach for all
static assets. See Local assets for more information on how local assets are configured
and served as part of the standard Django staticfiles approach, along with details on the
integration of other components and some known issues.
Endpoints¶
The websocket and direct http message endpoints are separately configurable. The configuration options exist to satisfy two requirements
- Isolate paths that require serving with ASGI. This allows the asynchronous routes - essentially the websocket connections and any other ones from the rest of the application - to be served using
daphne
or similar, and the bulk of the (synchronous) routes to be served using a WSGI server such asgunicorn
.- Isolate direct http posting of messages to restrict their use. The motivation behind this http endpoint is to provide a private service that allows other parts of the overall application to send notifications to
Dash
applications, rather than expose this functionality as part of the public API.
A reverse proxy front end, such as nginx
, can route appropriately according to URL.
View decoration¶
Each view delegated through to plotly_dash
can be wrapped using a view decoration function. This enables access to be restricted to
logged-in users, or using a desired conditions based on the user and session state.
To restrict all access to logged-in users, use the login_required
wrapper:
PLOTLY_DASH = {
...
# Name of view wrapping function
"view_decorator": "django_plotly_dash.access.login_required",
...
}
More information can be found in the view decoration section.
Initial arguments¶
Initial arguments are stored within the server between the specification of an app in a template tag and the invocation of the
view functions for the app. This storage is transient and can be efficiently performed using Django’s caching framework. In some
situations, however, a suitably configured cache is not available. For this use case, setting the cache_arguments
flag to False
will
cause initial arguments to be placed inside the Django session.