Snipe-it: APP_TRUSTED_PROXIES on docker image

[hrdkgtm]

Please confirm you have done the following before posting your bug report:

• [x] I have enabled debug mode
• [x] I have read checked the Common Issues page

Describe the bug
The only way to modify APP_TRUSTED_PROXIES of snipe-IT on docker is to change the config/trustedproxy.php after the image is running.

To Reproduce
Steps to reproduce the behavior:

1. Put APP_TRUSTED_PROXIES on your docker env file
2. docker exec -it cat .env
3. see that there is actually no APP_TRUSTED_PROXIES mentioned and/or taken from the docker env file

Expected behavior
the docker image .env should reflect as much as possible as deployments using other methods. it's just confusing for someone like me who utilize services such as cloudflare SSL, and extensive number of reverse proxies to connect to the snipe-IT. and having to come in the container and change manually everytime is a little bit inefficient and time consuming

Screenshots

# --------------------------------------------
# REQUIRED: BASIC APP SETTINGS
# --------------------------------------------
#APP_ENV=develop
#APP_DEBUG=false
#APP_KEY=Change_this_key_or_snipe_will_get_ya
#APP_URL=http://127.0.0.1:32782
#APP_TIMEZONE=US/Pacific
#APP_LOCALE=en


# --------------------------------------------
# REQUIRED: DATABASE SETTINGS
# --------------------------------------------
DB_CONNECTION=mysql
DB_HOST=${MYSQL_PORT_3306_TCP_ADDR}
DB_PORT=${MYSQL_PORT_3306_TCP_PORT}
DB_DATABASE=${MYSQL_DATABASE}
DB_USERNAME=${MYSQL_USER}
DB_PASSWORD=${MYSQL_PASSWORD}
DB_PREFIX=null
DB_DUMP_PATH='/usr/bin'


# --------------------------------------------
# REQUIRED: OUTGOING MAIL SERVER SETTINGS
# --------------------------------------------
MAIL_DRIVER=smtp
MAIL_HOST=${MAIL_PORT_587_TCP_ADDR}
MAIL_PORT=${MAIL_PORT_587_TCP_PORT}
MAIL_USERNAME=${MAIL_ENV_USERNAME}
MAIL_PASSWORD=${MAIL_ENV_PASSWORD}
MAIL_ENCRYPTION=${MAIL_ENV_ENCRYPTION}
MAIL_FROM_ADDR=${MAIL_ENV_FROM_ADDR}
MAIL_FROM_NAME=${MAIL_ENV_FROM_NAME}
MAIL_REPLYTO_ADDR=${MAIL_ENV_FROM_ADDR}
MAIL_REPLYTO_NAME=${MAIL_ENV_FROM_NAME}


# --------------------------------------------
# REQUIRED: IMAGE LIBRARY
# This should be gd or imagick
# --------------------------------------------
IMAGE_LIB=gd


# --------------------------------------------
# OPTIONAL: SESSION SETTINGS
# --------------------------------------------
SESSION_LIFETIME=12000
EXPIRE_ON_CLOSE=false
ENCRYPT=false
COOKIE_NAME=snipeit_session
COOKIE_DOMAIN=null
SECURE_COOKIES=false


# --------------------------------------------
# OPTIONAL: CACHE SETTINGS
# --------------------------------------------
CACHE_DRIVER=file
SESSION_DRIVER=file
QUEUE_DRIVER=sync

Server (please complete the following information):

• Snipe-IT Docker:v4.6.15
• OS: Docker

Additional context

• Is this a fresh install or an upgrade?
  
  
  
  • Fresh
  
  
• What OS and web server you're running Snipe-IT on
  
  
  
  • OpenSUSE Kubicmaster, Kubernetes + cri-o
  
  
• What method you used to install Snipe-IT (install.sh, manual installation, docker, etc)
  
  
  
  • Docker
  
  
• Include what you've done so far in the installation, and if you got any error messages along the way.
  
  
  
  • pull the image, configure environment variables for snipe-it and mysql, configure manually inside the container to accept all proxies
  
  
• Indicate whether or not you've manually edited any data directly in the database
  
  
  
  • not database, but config files at config/trustedproxy.php
  
  

Please do not post an issue without answering the related questions above. If you have opened a different issue and already answered these questions, answer them again, once for every ticket. It will be next to impossible for us to help you.

[stale[bot]]

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

[cstrock]

This issue is still occurring.
If you pass APP_TRUSTED_PROXIES= x.x.x.x (via .env file) then it doesn't end up in the trustedproxy.php file.

[stale[bot]]

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

[acidicX]

I have the same issue. Is there any workaround for the time being?
I've tried to edit the files in the container directly but with no success.

/edit
Note that this also does not work with develop or v5.0.0-beta-2.

[acidicX]

@snipe I'd be happy to contribute but I am missing how the Docker env is piped through to the webapp, can you maybe point me to the right files to debug this further?

[hrdkgtm]

Hey its been a while since i didn't check on this. I'm also down to check things further when I have time.
but I am not sure if this issue still occurs with the v4.7.5 of snipe-it. anyone tested it yet?

[acidicX]

I've got it nearly working now.

My nginx config:

# Snipe-IT Docker Daemon
upstream snipe-it-docker {
        server 127.0.0.1:5544 max_fails=0;
}

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        # change hostname and certs
        server_name snipeit.myhost.tld;
        ssl_certificate /path/to/certs/fullchain.pem;
        ssl_certificate_key /path/to/certs/privkey.pem;

        if ($scheme != "https") {
                return 301 https://$host$request_uri;
        }

        location / {
                proxy_http_version 1.1;
                client_max_body_size 100M;
                proxy_set_header Host $http_host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header X-Frame-Options SAMEORIGIN;
                proxy_buffers 256 16k;
                proxy_buffer_size 16k;
                proxy_read_timeout 600s;
                proxy_pass http://snipe-it-docker;
        }
}

The docker-compose:

version: '3'

services:

  app:
    image: snipe/snipe-it
    restart: unless-stopped
    env_file: snipeit.env
    ports:
      - 127.0.0.1:5544:80
    environment:
      - APP_KEY=your_key
      - APP_URL=https://snipeit.host.tld
      - APP_TRUSTED_PROXIES="192.168.0.0/24,10.0.0.0/24,127.0.0.1"
      - [email protected]
      - [email protected]
    depends_on:
      - db
      - mail
    volumes:
      - ./volumes/snipeit:/var/lib/snipeit

  db:
    image: mariadb/server
    restart: unless-stopped
    env_file: snipeit.env
    volumes:
      - ./volumes/mysql:/var/lib/mysql

  mail:
    image: catatnight/postfix
    restart: unless-stopped
    environment:
      - maildomain=peerigon.com
      - smtp_user=postfix:postfix

The only remaining problem

Even though my nginx does TLS and my clients come in with https, snipe-it puts out http URLs which will not work obviously. Is there a setting to force https scheme in snipe-it?

[acidicX]

Ok this is still the app trusted proxies issue. After manually editing the config/trustedproxies.php and setting it to "*" it works. Seems to be broken inside the docker setup.

[stale[bot]]

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

[acidicX]

Yes and it would be nice if this happens or if somebody can point us in the direction of where to fix this, I can't find anything related to the docker image generation.

[stale[bot]]

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

[stale[bot]]

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

[vgrassia]

I'm also experiencing this issue. Please let me know if I can be of any help resolving it.

[stale[bot]]

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

[samcgarry]

I've also noticed this problem.
If I shell into the docker container the APP_TRUSTED_PROXIES environment variable is set correctly, but it just does not seem to be read by Laravel in config/trustedproxy.php.

I'm using a compose file so I've set up a bind mount within that to allow me to persist the changes to trustedproxy.php for now, i.e.

• ./trustedproxy.php:/var/www/html/config/trustedproxy.php

Then in the host copy of trustedproxy I've set the APP_TRUSTED_PROXIES environment variable to *.

[stale[bot]]

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

[acidicX]

still unfixed :(

[stale[bot]]

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

[stale[bot]]

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

[stale[bot]]

This issue has been automatically closed because it has not had recent activity. If you believe this is still an issue, please confirm that this issue is still happening in the most recent version of Snipe-IT and reply to this thread to re-open it.

[wischi-chr]

Tried it right now (with v5.0.0-beta-4) and it's still not working.

[snipe]

@uberbrady can you take a peek at this one?

[stale[bot]]

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

[wischi-chr]

I've also noticed this problem.
If I shell into the docker container the APP_TRUSTED_PROXIES environment variable is set correctly, but it just does not seem to be read by Laravel in config/trustedproxy.php.

I'm using a compose file so I've set up a bind mount within that to allow me to persist the changes to trustedproxy.php for now, i.e.

• ./trustedproxy.php:/var/www/html/config/trustedproxy.php

Then in the host copy of trustedproxy I've set the APP_TRUSTED_PROXIES environment variable to *.

@samcgarry Thank you, the workaround worked like a charme.

[uberbrady]

I don't think it will be too hard to surface the APP_TRUSTED_PROXIES variable to the docker environment. I'm on it.

[wischi-chr]

Maybe I'm a bit naive but why doesn't snipe-it just use the exact string set for APP_URL as baseurl?

[snipe]

@wischi-chr It's not a naive question. IIRC, we had to make a lot of changes to the way urls work because of different user environments (subdirectories, reverse proxies, load balancers, etc). We made those changes years ago to handle various issues users were having. I'm sorry I don't recall all of the specifics, but I swear there was a reason for it.

[snipe]

It's kind of frustrating TBH. Laravel is a great framework, but in some ways it's not exactly friendly to people building open source software and we've had to do some funky stuff to make it work across tons of different environments.

[uberbrady]

Okay, I've dug a little bit into this. This gets VERY confusing because there are several different senses of the word "Environment" in use here. First off, we have your Docker --env-file. That's the "environment" that we specify to Docker, which gets passed-in to Snipe-IT. Then there's Snipe-IT's .env file, which is a standard file for all Laravel installations. Then there's the actual operating application environment - which is informed by the .env file but may also pick up pieces of environment data from elsewhere - most significantly, from the Linux "Environment variable" system - the stuff that populates and propagates things like $HOME and $PATH and so on.

The way our Docker integration is supposed to work is that pretty much anything you specify in your docker --env-file file will get silently passed onwards to the real, actual _environment_ of the docker instance. It may not be in the .env file, but it will be in the actual environment, and will be read by the actual Snipe-IT software. We specify a 'stub' .env file for you that helps negotiate between some docker-provided environment variables and our Snipe-IT environment variables, but we're still expecting that everything you set in your Docker environment should get passed forward, without modification, to Snipe-IT's environment.

So how I built the Docker integration is: anything I specify something in my Docker --env-file will show up in Snipe-IT's operating environment. Period. I just did a test by specifying APP_TRUSTED_PROXIES in my Docker --env-file of 127.0.0.1,192.168.0.0,*. Then I went into the config/trustedproxy.php and put in a line (before the return) of: dd("Trusted Proxies are: ".env('APP_TRUSTED_PROXIES'));. (The dd() command means "Display And Die", it dumps out output and then immediately crashes on purpose). So, of course, my installation is messed up, but I should be able to see if the environment is being correctly modified.

The output I get is:

"Trusted Proxies are: 127.0.0.1,192.168.0.0,*"

So that means that the APP_TRUSTED_PROXIES setting that I specified in my --env-file is being propagated correctly to my Docker environment, and Snipe-IT is reading the value of that environment variable correctly.

One of the disadvantages of the approach we have is that, to change any environment variable at all, you need to restart the container. This sucks, but that's how I built it. The idea should be that the Docker container itself is so transient and disposable that this isn't a very big deal, but, maybe it is. I'm definitely open to other suggestions.

There is still a possibility that some of the Docker environments that we have set up are not propagating environment variables properly, but I can't reproduce it now.

If you folks who are still having the environment variables not get read correctly could try to reproduce my test, that would be really helpful. Again, the big deal to remember is you need to restart your Docker container any time you modify your Docker environment variables.

My worry is that some weird piece of Apache2 management that we do - enabling/disabling modules - somehow is blowing out the read-in environment. But if that were the case I would expect literally nothing to work at all, since our stub .env doesn't really have enough environment data to run Snipe-IT.

Thanks for the excellent bug reports and workarounds - as soon as we can get your issues to reproduce on my local Docker environment, I know I'll be able to fix it for you all, in both the 4.9.x branch as well as the new 5.x branch.

[uberbrady]

Updated the docker documentation with a nice big shiny red box explaining this (in very short). Closing.