opened
dsperling
username_0
You cannot use the `admin` application inside a Docker container, even when accessing the container from the host with `http://127.0.0.1:8080/admin`.  The user gets the message:  `Admin is disabled because insecure channel`.

This is due to the Docker Network bridge and the fact that the connections into the container's web server do not happen over `127.0.0.1:8080` but rather `172.17.0.1:8080`.

Our [current workaround](https://github.com/smithmicro/web2py/blob/master/nginx.conf) for this issue to to add an nginx web server container configured for HTTPS using self-signed certificates.  The downside to this is that you have to click through the unsafe site warnings in your browser.  There might be a better way to allow access to the `admin` application inside a container that we have not yet discovered.

**Question**: other than the `DEMO_MODE` variable which only gives read-only access to `admin`, is there any way to bypass the security checks in front of the `admin` application?  

If this does not exist, then a **feature request** would be to add an environment variable (or Python variable) like `WEB2PY_ADMIN_SECURITY_BYPASS=1` to explicitly bypass the `admin` security checks.

To reproduce this issue, run the following Docker command:
```
docker run -it -p 8080:8080 smithmicro/web2py
```
Then open:
http://127.0.0.1:8080/admin

Our Dockerized Web2py project is located here:
https://github.com/smithmicro/web2py
Admin application within a Docker Container
issue
created
dsperling
username_0
Thanks for the suggestions.  We will give this a try.
comment
created
dsperling
username_0
@username_1 - I figured out the last issue above.   Here is the final bash script:
```
if [ "$WEB2PY_CONTAINER_IP" != '' ]; then
  python -c "from gluon.main import save_password; save_password('$WEB2PY_PASSWORD',80)"
  sed -i -e "\$acontainer_ip = os.environ.get('WEB2PY_CONTAINER_IP', None)" \
    /opt/web2py/applications/admin/models/0.py
  sed -i "s/elif not request.is_local and not DEMO_MODE:/elif not request.is_local and not DEMO_MODE and not request.env.remote_addr == container_ip:/" \
    /opt/web2py/applications/admin/models/access.py
  sed -i "s/local_hosts = set(\[/local_hosts = set(\[os.environ.get('WEB2PY_CONTAINER_IP', None), /" \
    /opt/web2py/gluon/main.py
fi
```
Thanks for your help.  Closing.
comment
closed
dsperling
username_0
issue
created
leonelcamara
username_1
Consider making a pull request actually making those changes in the admin's code, there's a chance later changes could break your script.
comment
created
dsperling
username_0
@username_1 I have refactored the feature bypass in my Docker image.  The problem is that Docker changes the network IP address range depending on the number of bridge networks created.  This would make it difficult to to create examples that work out of the box.

For now we have decided to use the following code to bypass the security checks for any IP address.  This increases the risk of someone deploying it, but hopefully the name of the variable offers the proper warning.  This is not appropriate to do a PR with.

```
 if [ "$WEB2PY_ADMIN_SECURITY_BYPASS" = 'true' ]; then
    if ["$WEB2PY_PASSWORD" = '']; then
      echo "ERROR - WEB2PY_PASSWORD not specified"
      exit 1
    fi
    echo "WARNING! - Admin Application Security over HTTP bypassed"
    python -c "from gluon.main import save_password; save_password('$WEB2PY_PASSWORD',8080)"
    sed -i "s/elif not request.is_local and not DEMO_MODE:/elif False:/" \
      $WEB2PY_ROOT/applications/admin/models/access.py
    sed -i "s/is_local=(env.remote_addr in local_hosts and client == env.remote_addr)/is_local=True/" \
      $WEB2PY_ROOT/gluon/main.py
  fi
```

However, we could create a secure version of this by making the `is_local` variable in `gluon/main.py` able to detect **if hosts are connecting over the same subnet**.  If so, this would work for both 127.0.0.1 and Docker container scenarios.  Maybe this is the long term fix for a container friendly Web2py admin app.
comment