Debug toolbar doesn't works through browserify in a Docker Container

[SalahAdDin]

I'm using debug-toolbar for debug my project but i have a problem using it through browserify.

This is the normal behaviour: As you can see debug-toolbar is working behind port 3000 without problems.

I had the problem with normal port, but i solved it like people said:

INTERNAL_IPS = ['::1', '172.18.0.1']
# Modify second value accord your Docker configuration:
#    docker inspect uzman_web_1 | grep -e '"Gateway"'

And the result is correct:

But through browserify it doesn't works:

Why? Can anyone help to me?

[matthiask]

I'd try overriding SHOW_TOOLBAR_CALLBACK with a version that always returns True during development. Maybe that's sufficient?

[SalahAdDin]

which code did you use?

[matthiask]

I didn't, it was just a suggestion.

Something like:

# app/utils.py
from django.conf import settings
def show_toolbar(request):
    return bool(settings.DEBUG)

and

# app/settings.py
SHOW_TOOLBAR_CALLBACK = 'yourapp.utils.show_toolbar'

I'm not saying that's a good idea though -- the restrictions are there for a reason, and if ever the Debug Toolbar would be visible to arbitrary visitors you'd be exposing lots and lots of information about your setup. You should be really really careful.

[SalahAdDin]

But this behaviour is very strange, i mean, in local environmet (not docker), debug-toolbar works through browserify without need use any other function.

Why have we use this little function for make work it?

[hyshka]

I get the same behavior through BrowserSync inside of a Docker container. Overriding the SHOW_TOOLBAR_CALLBACK function is a valid workaround for me.

[japrogramer]

You can still see the debug panel in a docker container if you set up middleware to check /proc/net/arp for new ips on every new request, than appending that ip addr as a set into INTERNAL_IPS.

[SalahAdDin]

@japrogramer how can it set up the middlerware in these way?

[japrogramer]

like this, you might need to refresh the page for the first time landing on your site. Than after, DDT will be visible.

class arpMiddleware(object):
    def __init__(self, get_response):
        self.get_response = get_response
        # One-time configuration and initialization.

    def __call__(self, request):
        # Code to be executed for each request before
        # the view (and later middleware) are called.
        with open('/proc/net/arp') as arp:
            for line in arp:
                fields = line.split()
                if any('eth' in s for s in fields):
                    from django.conf import settings
                    settings.INTERNAL_IPS = list(set(settings.INTERNAL_IPS + [fields[0]]))
                if any('eth0' in s for s in fields):
                    print('DJANGO DEBUG TOOLBAR ___ OK')

        response = self.get_response(request)

        # Code to be executed for each request/response after
        # the view is called.

        return response

[tim-schilling]

Is this still an issue when using the following in your settings?

if DEBUG:
    import socket  # only if you haven't already imported this
    hostname, _, ips = socket.gethostbyname_ex(socket.gethostname())
    INTERNAL_IPS = [ip[: ip.rfind(".")] + ".1" for ip in ips] + ["127.0.0.1", "10.0.2.2"]