[Bug]: auth provider redirect URL is wrong for custom public API port
Contact Details
No response
What happened?
Hi,
it seems like a custom API public port is not considered properly for the redirect URL given to OAuth providers. Whenever I try to log in via SSO on my Netmaker dashboard deployed using Docker Compose, I get redirected to port 443 on https://api.NM_DOMAIN/api/oauth/callback.
Therefore, I started looking into the source code and found out that
https://github.com/gravitl/netmaker/blob/089df3d4cffe3723ed1563ba01da05eab5962d94/auth/auth.go#L84C2-L91C3
seems to be the issue, because APIHost shouldn't contain the public port. Currently, my setup looks like the following:
I replaced Caddy with an nginx reverse proxy container for testing, but the issue was already occurring with Caddy.
docker-compose.yml:
version: "3.4"
services:
netmaker:
container_name: netmaker
image: gravitl/netmaker:$SERVER_IMAGE_TAG
env_file: ./netmaker.env
restart: always
volumes:
- dnsconfig:/root/config/dnsconfig
- sqldata:/root/data
environment:
# config-dependant vars
- STUN_LIST=stun1.netmaker.io:3478,stun2.netmaker.io:3478,stun1.l.google.com:19302,stun2.l.google.com:19302
# The domain/host IP indicating the mq broker address
- BROKER_ENDPOINT=wss://broker.${NM_DOMAIN}:14145 # For EMQX broker use `BROKER_ENDPOINT=wss://broker.${NM_DOMAIN}/mqtt`
# For EMQX broker (uncomment the two lines below)
#- BROKER_TYPE=emqx
#- EMQX_REST_ENDPOINT=http://mq:18083
# The base domain of netmaker
- SERVER_NAME=${NM_DOMAIN}
- SERVER_API_CONN_STRING=api.${NM_DOMAIN}:14145
# Address of the CoreDNS server. Defaults to SERVER_HOST
- COREDNS_ADDR=${SERVER_HOST}
# Overrides SERVER_HOST if set. Useful for making HTTP available via different interfaces/networks.
#- SERVER_HTTP_HOST=api.${NM_DOMAIN}
netmaker-ui:
container_name: netmaker-ui
image: gravitl/netmaker-ui:$UI_IMAGE_TAG
env_file: ./netmaker.env
environment:
# config-dependant vars
# URL where UI will send API requests. Change based on SERVER_HOST, SERVER_HTTP_HOST, and API_PORT
BACKEND_URL: "https://api.${NM_DOMAIN}:14145"
depends_on:
- netmaker
links:
- "netmaker:api"
restart: always
nginx:
image: nginx:alpine-slim
volumes:
- "./proxy.conf:/etc/nginx/conf.d/default.conf"
- "/etc/letsencrypt/live/${NM_DOMAIN}/fullchain.pem:/etc/letsencrypt/live/${NM_DOMAIN}/fullchain.pem"
- "/etc/letsencrypt/live/${NM_DOMAIN}/privkey.pem:/etc/letsencrypt/live/${NM_DOMAIN}/privkey.pem"
ports:
- "14135:80"
- "14145:443"
restart: always
coredns:
network_mode: host
container_name: coredns
image: coredns/coredns:1.10.1
command: -conf /root/dnsconfig/Corefile
env_file: ./netmaker.env
depends_on:
- netmaker
restart: always
volumes:
- dnsconfig:/root/dnsconfig
mq:
container_name: mq
image: eclipse-mosquitto:2.0.15-openssl
env_file: ./netmaker.env
depends_on:
- netmaker
restart: unless-stopped
command: [ "/mosquitto/config/wait.sh" ]
volumes:
- ./mosquitto.conf:/mosquitto/config/mosquitto.conf
- ./wait.sh:/mosquitto/config/wait.sh
- mosquitto_logs:/mosquitto/log
- mosquitto_data:/mosquitto/data
volumes:
caddy_data: { } # runtime data for caddy
caddy_conf: { } # configuration file for Caddy
sqldata: { }
dnsconfig: { } # storage for coredns
mosquitto_logs: { } # storage for mqtt logs
mosquitto_data: { } # storage for mqtt data
netmaker.env:
NM_EMAIL=<hidden>
NM_DOMAIN=<hidden>
UI_IMAGE_TAG=v0.22.0
NETMAKER_TENANT_ID=
LICENSE_KEY=
SERVER_IMAGE_TAG=v0.22.0
SERVER_HOST=<hidden>
MASTER_KEY=<hidden>
MQ_USERNAME=netmaker
MQ_PASSWORD=<hidden>
INSTALL_TYPE=ce
NODE_ID=netmaker-server-1
DNS_MODE=on
NETCLIENT_AUTO_UPDATE=enabled
API_PORT=8081
CORS_ALLOWED_ORIGIN=*
DISPLAY_KEYS=on
DATABASE=sqlite
SERVER_BROKER_ENDPOINT=ws://mq:1883
VERBOSITY=1
DEBUG_MODE=off
REST_BACKEND=on
DISABLE_REMOTE_IP_CHECK=off
TELEMETRY=on
AUTH_PROVIDER=oidc
CLIENT_ID=<hidden>
CLIENT_SECRET=<hidden>
FRONTEND_URL=https://<hidden>:14145
AZURE_TENANT=
OIDC_ISSUER=<hidden>
EXPORTER_API_PORT=8085
JWT_VALIDITY_DURATION=43200
RAC_AUTO_DISABLE=true
CACHING_ENABLED=true
METRICS_EXPORTER=off
PROMETHEUS=off
Although I'm using v0.22.0, the bug doesn't seem to be fixed in v0.23.0 according to the source code, so I don't think upgrading would fix the problem.
Version
v0.22.0
What OS are you using?
No response
Relevant log output
No response
Contributing guidelines
- [X] Yes, I did.
I see the issue, we will try to fix this in the next release thanks for reporting.