linkwarden
linkwarden copied to clipboard
linkwarden
Not working with reverse proxy
I spinned up a new instance using docker, using your docker-compose.yml (cloned the repo). Created a .env file with: NEXTAUTH_SECRET=new_key NEXTAUTH_URL=https://link.example.com POSTGRES_PASSWORD=other_new_key
The docker logs indicate: linkwarden_1 | - ready started server on 0.0.0.0:3000, url: http://localhost:3000 (please note the url displayed)
When I try in browser to go to https://link.example.com I get a 503 error code.
It seems that the docker environment is not taking the .env parameter NEXTAUTH_URL=https://link.example.com into account.
Any help greatly appreciated.
On the same server already serving 12 other services with the same method and they all work.
Hello @airdogvan,
Please make sure to specify the port as well:
NEXTAUTH_URL=https://link.example.com:3000
Thank you for the suggestion but my reverse proxy takes care of exposing the correct port. In the docker-compose file I add in the environment: - VIRTUAL_HOST=link.example.com - VIRTUAL_PORT=3000
I knew it wouldn't work but tried your suggestion anyway and it didn't work.
To me it seems that your app is really using the config it displays in the logs, in this case: http://localhost:3000
So did it work after defining VIRTUAL_HOST and VIRTUAL_PORT?
Honestly, the Cloud instance is using the manual installation so I haven't tried deploying it to production using docker, I only tested the docker installation locally.
As said NO, it did NOT work. Again, I can't see behind the code but the logs seem to be telling the truth, http://localhost:3000/ is the link that your app is working with, even though in the .env file specified otherwise...
I do not understand, it's clearly said in the docs that you should NOT specify NEXTAUTH_URL.
I haven't and linkwarden with reverse proxy functions correctly.
Not sure where in the docs you read that. I tried removing NEXTAUTH_URL and it still doesn't work. As said on same host have many services running many services through that reverse proxy and they all work, so quite sure it's not a problem in my setup.
@ser Are you using the IP of the service instead of the domain name?
I read it in the docs, https://docs.linkwarden.app/self-hosting/installation
I am sure that problem is in your setup as mine works without any single issue. I have only NEXTAUTH_SECRET and DATABASE_URL set. Reverse proxy is told to use IP address of the docker and port of the linkwarden container.
I spinned up a new instance using docker, using your docker-compose.yml (cloned the repo). Created a .env file with: NEXTAUTH_SECRET=new_key NEXTAUTH_URL=https://link.example.com POSTGRES_PASSWORD=other_new_key
The docker logs indicate: linkwarden_1 | - ready started server on 0.0.0.0:3000, url: http://localhost:3000 (please note the url displayed)
When I try in browser to go to https://link.example.com I get a 503 error code.
It seems that the docker environment is not taking the .env parameter NEXTAUTH_URL=https://link.example.com into account.
Any help greatly appreciated.
On the same server already serving 12 other services with the same method and they all work.
same here for nginx proxy
Please let me know if this works: https://github.com/linkwarden/linkwarden/issues/269#issuecomment-1789985391
I haven't tried it. The reason is: every port you're directly exposing on internet is asking for more trouble by increasing the attack surface for bad intentioned actors. This is why there are reverse proxies that take care of redirecting those ports on the internal network.
This is very bad security practice, If your service needs internal communication keep it internal.
For instance in a docker service you would do something such as:
service a: name mysql mysql
service b: name my_app my_app depends_on: mysq
mysql_url: mysql:3306
This way the mysql port is not exposed to internet and my_app can communicate on docker's internal network.
Unsure if this will help you guys, but this is my Traefik setup, works flawlessly.
##~~~~~~~~~~~~~~~~##
##Bookmark Manager##
##~~~~~~~~~~~~~~~~##
linkwarden:
container_name: Linkwarden
image: ghcr.io/linkwarden/linkwarden:latest
environment:
- DATABASE_URL=postgresql://${LINKWRDNDBUSER}:${LINKWRDNDBPASS}@linkwardendb:5432/postgres
- NEXTAUTH_SECRET=$NEXTAUTHSECRET
- NEXTAUTH_URL=https://bookmark.$DOMAINNAME/api/v1/auth
- NEXT_PUBLIC_DISABLE_REGISTRATION=true
networks:
pihole:
ipv4_address: '172.22.0.131'
isolated:
ports:
- 45514:3000
volumes:
- $USERDIR/Linkwarden/data:/data/data
logging:
driver: "local"
options:
max-size: 10m
max-file: "3"
labels:
- autoheal=true
- "traefik.enable=true"
## HTTP Routers
- "traefik.http.routers.linkwarden-rtr.entrypoints=https"
- "traefik.http.routers.linkwarden-rtr.rule=Host(`bookmark.$DOMAINNAME`)"
## Middlewares
- "traefik.http.routers.linkwarden-rtr.middlewares=chain-no-auth@file" # No Authentication
# - "traefik.http.routers.linkwarden-rtr.middlewares=chain-oauth@file" # Google OAuth 2.0
# - "traefik.http.routers.linkwarden-rtr.middlewares=chain-authelia@file" # Authelia
## HTTP Services
- "traefik.http.routers.linkwarden-rtr.service=linkwarden-svc"
- "traefik.http.services.linkwarden-svc.loadbalancer.server.port=3000"
## Homepage
- homepage.name=Linkwarden
- homepage.group=Other
- homepage.icon=https://raw.githubusercontent.com/linkwarden/linkwarden/main/assets/logo.png
- homepage.href=https://bookmark.$DOMAINNAME
depends_on:
- linkwardendb
restart: always
linkwardendb:
container_name: LinkwardenDB
image: postgres:alpine
environment:
- POSTGRES_PASSWORD=$LINKWRDNDBPASS
logging:
driver: "local"
options:
max-size: 10m
max-file: "3"
networks:
isolated:
restart: always
volumes:
- $USERDIR/Linkwarden/db:/var/lib/postgresql/data
As said NO, it did NOT work. Again, I can't see behind the code but the logs seem to be telling the truth, http://localhost:3000/ is the link that your app is working with, even though in the .env file specified otherwise...
Goshh... You angry? Get some fresh air outside man... You configuration is wrong, maybe you should better understand how traefik works before yelling at people...
- "traefik.http.services.linkwarden.loadbalancer.server.port=3000"
This will work without exposing any ports of your containers.
Have a nice day.
As said NO, it did NOT work. Again, I can't see behind the code but the logs seem to be telling the truth, http://localhost:3000/ is the link that your app is working with, even though in the .env file specified otherwise...
I faced the same issue and I fixed it by adding a line with PORT=xyz in the .env file, with xyz being the port I wanted to use instead of the default value of 3000. I guess the NEXTAUTH_URL has to also be changed to use the same port number.
For reference, I found the way to change the port there : https://stackoverflow.com/questions/60245994/how-can-i-change-the-default-port-in-react-from-3000-to-another-port
Just wanted to say that it now works for me. docker-compose.yml
version: "3.5"
services:
postgres:
image: postgres:16-alpine
env_file: .env
restart: always
volumes:
- ./pgdata:/var/lib/postgresql/data
networks:
- link_back
linkwarden:
env_file: .env
environment:
- DATABASE_URL=postgresql://postgres:${POSTGRES_PASSWORD}@postgres:5432/postgres
- VIRTUAL_HOST=linkwarden.example.com
- LETSENCRYPT_HOST=linkwarden.example.com
- [email protected]
- VIRTUAL_PORT=3000
restart: always
# build: . # uncomment this line to build from source
image: ghcr.io/linkwarden/linkwarden:latest # comment this line to build from source
volumes:
- ./data:/data/data
depends_on:
- postgres
networks:
- link_back
- nginx-proxy_proxy
networks:
link_back:
nginx-proxy_proxy:
external: true
Please note that port 3000 is exposed as virtual, not visible from the host but only inside container network.
.env
NEXTAUTH_SECRET=SDFSDfghjgj345#$%sdfRY
NEXTAUTH_URL=http://linkwarden.example.com/api/v1/auth
# Manual installation database settings
#DATABASE_URL=postgresql://user:xxxxd@localhost:5432/linkwarden
# Docker installation database settings
POSTGRES_PASSWORD=xxxx
Not sure if something changed in the code or if I made a mistake in mine.
Now works fine.
As far as I'm concerned, this issue can be closed.
Very nice app, much appreciate!.
@airdogvan probably not too big of a deal if its local only, and maybe you have acted on it already, but in your last message you have published your nextauth secret.
