Closed yenaing-oo closed 2 days ago
@danloveg
I found that even though DEBUG
is set to True
in docker_dev.py
, DEBUG
itself never actually got passed as context to templates:
If you add the above without any other changes and open any page of the app on your browser, you will see that the else
condition is fired and the value of DEBUG
is empty.
It turns out that the debug
context processor only passes the debug
variable as context if the request made came from an IP that is listed in settings.INTERNAL_IPS
(a setting that has not been set yet), in addition to settings.DEBUG
being True
:
I tried adding this setting to docker_dev.py
:
INTERNAL_IPS = [
'127.0.0.1',
'localhost',
]
But this didn't work. Upon studying the value of self.request.META["REMOTE_ADDR"]
for a given request (say the About page), I discovered that the IP address is actually not localhost
('127.0.0.1'), but 192.168.65.1
instead.
It appears that Docker is intercepting any requests made by my local host and relaying it to the app
service using its own default IP address 192.168.65.1
.
I believe this IP address can be configured in Docker's settings here: , although the actual IP address on the request is slightly different (note the .1 at the end instead of .0).
Modifying this setting:
INTERNAL_IPS = [
'192.168.65.1'
]
and replacing any {% if DEBUG %}
with {% if debug %}
in the templates fixes this issue.
That makes sense. My question is, it seems like django-pipeline will send un-minified assets when DEBUG=True automatically - what happens when you try to use this without checking whether debug is true in the template?
{% load pipeline %}
{% javascript 'recordtransfer_base_js' %}
Or in other words, what error is thrown when you use that code when the pipeline is disabled?
Checking if debug is true:
Without checking if debug is true:
It doesn't look like any error is thrown:
Okay, so when you don't check is how you get three versions of the same file.
My concern is about the IP address, I don't know whether we can assume everyone's Docker (or Podman) network will be set to 192.168.65.0/24
. I wonder if we can't just make a custom context processor that doesn't have that requirement.
Other context processors can be found here: https://github.com/NationalCentreTruthReconciliation/Secure-Record-Transfer/blob/master/bagitobjecttransfer/recordtransfer/context_processors.py
Yes, that would work too! I'll make one. I agree about the IP address not guaranteed to be the same for everyone's container network.
Sounds great, thanks
Closing in favour of #247
Minified CSS and JS should not be generated when running in development. This causes issues such as the same JS running 3 times: