[Bug]: Env Variables are not read by Application when running via Docker

[jawabuu]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Application in Docker container is not reading env variables defined when starting up container.
Consequently, navigating to {url}/login returns a 500 error

Expected Behavior

After setting required env variables, navigating to {url}/login should trigger auth flow

version

leplusorg/openid-connect-provider-debugger:main

Relevant log output

Confirm envs are present in the container

$ docker run -i -e 'oidc_client_id=kbyuFDidLLm280LIwVFiazOqjO3ty8KH' -e 'oidc_client_secret=60Op4HFM0I8ajz0WdiStAbziZ-VFQttXuxixHHs2R7r7-CW8GR79l-mmLqMhc-Sa' -e 'oidc_discovery=https://samples.auth0.com/.well-known/openid-configuration' -e 'oidc_redirect_uri=http://localhost:8111/token' -p 8111:80 leplusorg/openid-connect-provider-debugger:main env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/openresty/luajit/bin:/usr/local/openresty/nginx/sbin:/usr/local/openresty/bin
HOSTNAME=388aa41521a9
oidc_discovery=https://samples.auth0.com/.well-known/openid-configuration
oidc_redirect_uri=http://localhost:8111/token
oidc_client_id=kbyuFDidLLm280LIwVFiazOqjO3ty8KH
oidc_client_secret=60Op4HFM0I8ajz0WdiStAbziZ-VFQttXuxixHHs2R7r7-CW8GR79l-mmLqMhc-Sa
HOME=/root

Steps To Reproduce

1. In Docker environment
2. With this config

docker run -i -e 'oidc_client_id=kbyuFDidLLm280LIwVFiazOqjO3ty8KH' -e 'oidc_client_secret=60Op4HFM0I8ajz0WdiStAbziZ-VFQttXuxixHHs2R7r7-CW8GR79l-mmLqMhc-Sa' -e 'oidc_discovery=https://samples.auth0.com/.well-known/openid-configuration' -e 'oidc_redirect_uri=http://localhost:8111/token' -p 8111:80 leplusorg/openid-connect-provider-debugger:main

1. Run

docker run -i -e 'oidc_client_id=kbyuFDidLLm280LIwVFiazOqjO3ty8KH' -e 'oidc_client_secret=60Op4HFM0I8ajz0WdiStAbziZ-VFQttXuxixHHs2R7r7-CW8GR79l-mmLqMhc-Sa' -e 'oidc_discovery=https://samples.auth0.com/.well-known/openid-configuration' -e 'oidc_redirect_uri=http://localhost:8111/token' -p 8111:80 leplusorg/openid-connect-provider-debugger:main

1. Navigate to localhost:8111/login
2. Observe error
   

$ docker run -i -e 'oidc_client_id=kbyuFDidLLm280LIwVFiazOqjO3ty8KH' -e 'oidc_client_secret=60Op4HFM0I8ajz0WdiStAbziZ-VFQttXuxixHHs2R7r7-CW8GR79l-mmLqMhc-Sa' -e 'oidc_discovery=https://samples.auth0.com/.well-known/openid-configuration' -e 'oidc_redirect_uri=http://localhost:8111/token' -p 8111:80 leplusorg/openid-connect-provider-debugger:main
2024/05/04 16:05:09 [notice] 1#1: using the "epoll" event method
2024/05/04 16:05:09 [notice] 1#1: openresty/1.25.3.1
2024/05/04 16:05:09 [notice] 1#1: built by gcc 13.2.1 20231014 (Alpine 13.2.1_git20231014)
2024/05/04 16:05:09 [notice] 1#1: OS: Linux 5.4.72-microsoft-standard-WSL2
2024/05/04 16:05:09 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2024/05/04 16:05:09 [notice] 1#1: start worker processes
2024/05/04 16:05:09 [notice] 1#1: start worker process 7
172.17.0.1 - - [04/May/2024:16:05:21 +0000] "GET /login HTTP/1.1" 500 585 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
2024/05/04 16:05:21 [debug] 7#7: *1 [lua] default.conf:39):50: options={"ssl_verify":"no"}
2024/05/04 16:05:21 [error] 7#7: *1 [lua] default.conf:39):52: oidc_client_id is not defined, client: 172.17.0.1, server: localhost, request: "GET /login HTTP/1.1", host: "localhost:8111"

Anything else?

No response

[thomasleplus]

Hi @jawabuu, seems like a regression. Let me investigate and come back to you. Thanks for opening this issue!

[thomasleplus]

@jawabuu I figured out the issue. Thanks again for signaling the issue. I hope that you will find the container useful otherwise feel free to open other issues to request features/changes or report issues. Cheers!

[jawabuu]

Thanks @thomasleplus
The envs are now being picked up and auth flow is triggered

However after auth, I'm always getting this

[thomasleplus]

I am reproducing the issue with Safari and Chrome. I am usually using Firefox which is why I didn't catch it. I have opened a separate issue #27 for tracking. This might take me a little longer to fix to be honest as it seems that nowadays these browser don't accept session cookies that are not delivered over SSL/TLS. Firefox makes an exception for localhost.