yusing
Non docker services
Hi,
this project is really interesting. Right now I'm using Traefik with Cloudflare, my homelab is based on Proxmox, with dockerized services but I also have standalone LXC/VMs.
I like the tight integration with docker, but reading the docs I didn't understand how to manage non-docker services (standalone LXCs or VMs).
Can I manually define those non-docker services? Where can I find this in the docs?
Thanks for the great work.
Hi, it's here: https://github.com/yusing/godoxy/wiki/Docker-labels-and-Route-Files#example-configappyml
And https://github.com/yusing/godoxy/wiki/Configurations#setting-up-providers
All non docker routes can be defined within route files, after adding them to GoDoxy config they will show up on the homepage.
I need to set it up and experiment with it a bit to understand better.
It's probably one of those cases for which it's easier to implement it than studying it. :)
You're not too into yaml editing, you may just use the UI editor on WebUI -> Config Editor
Provider files have to be created first or can be done directly in the UI?
This is just a reverse proxy you can choose cf tunnels / tailscale / netbird / anything you want to work with.
Pangolin is Traefik + Wireguard + UI packed together to replace the use of cloudflare tunnels.
I haven't tried Pangolin yet, so I say below might be wrong:
If you use Pangolin:
Pros:
- Probably easier for beginners to share some of your site with the others
- Might have a better experience if you prefer UI over CLI. The current state of GoDoxy's UI is far from complete
Cons:
- You need rent a VPS to run it
- You lose the simplicity (from changing container name, to clicking buttons manually everytime you start a service)
- You'll have to setup Homepage, Beszel, Uptime Kuma, which these features are built-in to GoDoxy
- You'll lose the idle-sleep functionality
- You need rent a VPS to run it
You can run it without creating tunnels: https://docs.fossorial.io/Pangolin/without-tunneling
- You'll have to setup Homepage, Beszel, Uptime Kuma, which these features are built-in to GoDoxy
Yes, that's why I don't agree when you say in the first point that godoxy is "just a reverse proxy", it's a bit more, and that's why it's appealing for homelabbers. :)
Right now I'm using Traefik (with Cloudflare), Homepage, Beszel and Uptime-Kuma, all separately. What I like about godoxy is that it's one tool that covers all those functionalities. I hope the UI will improve with time.
I'll probably go with godoxy hoping to simplify operations/maintenance.
Last question: I'm using traefik integrated with Zitadel for IdP. I'm using this middleware to integrate Zitadel in Traefik. Hope I can do the same with godoxy.
just a reverse proxy
My bad, I mean from the connectivity aspect it's a reverse proxy, without wireguard and tunneling.
I hope the UI will improve with time.
I hope so, it will be great if someone can help. As you can see the only active contributor is me, the progress can be slow... And I'm a coding guy that's not too deep into web dev.
integrate Zitadel in Traefik. Hope I can do the same with godoxy.
From the page of the middleware:
PROVIDER_URL=...
CLIENT_ID=...
CLIENT_SECRET=...
which is similar to GoDoxy's configurations (See Wiki)
I hope so, it will be great if someone can help. As you can see the only active contributor is me, the progress can be slow... And I'm a coding guy that's not too deep into web dev.
I'm an old tinkerer, developed when I was young, now I just develop for hobby stuff (mainly Home Assistant python integrations). Never developed for web projects. I hope that when godoxy becomes more popular, some other dev will want to contribute, it is a nice project and you're doing a great job.
Once I install it and use it, and become proficient with it, I'll try to contribute as I can.
Keep up the great job...
which is similar to GoDoxy's configurations (See Wiki)
I'm using PKCE on Zitadel, and the middleware supports it:
I guess godoxy only supports client secret, right? If so, I need to configure another "application" in Zitadel, specific for godoxy.
Also, in the docs the callback url is mentioned, but not the logout url, in Zitadel there's both of them to configure. Would be nice to have them configurable in godoxy.
I guess the defaults should be:
https://*.yourdomain.com/auth/callbackhttps://*.yourdomain.com/auth/logout
Correct?
I guess godoxy only supports client secret, right? If so, I need to configure another "application" in Zitadel, specific for godoxy.
Yes does not support PKCE for now.
I guess the defaults should be:
https://*.yourdomain.com/auth/callbackhttps://*.yourdomain.com/auth/logoutCorrect?
Yes, correct
@yusing question: would it be possible to have something like ACLs (rules would be a more appropriate term) for the OIDC authentication? Right now, the middleware I'm using with traefik allows me to specify various rules to skip OIDC authentication. This is needed because I don't want LAN users or services to have to go through OIDC, but I surely want to force WAN users going through OIDC.
IP/CIDR would be basic rules, but I was also thinking if we could specify "all docker containers" / providers, etc. Something like that.
Ideally, if one uses cloudflared tunnel or cloudflare proxy, it would be awesome to say: "accept non LAN connections only through cloudflare or cloudflared, identify through cloudflare headers (real IP, etc.) and force OIDC. Something like that. :)
Bypassing OIDC / any middleware for specific IP range would be nice in many cases. Will add this in the next version.
For now there's no way to apply oidc globally to specific provider. You can use the middleware on the entry point, but it will cause many issues.
Bypassing OIDC / any middleware for specific IP range would be nice in many cases. Will add this in the next version.
Could you reuse the same kind of rules you have for ACLs? Those types of categories/rules are nice.
For now there's no way to apply oidc globally to specific provider. You can use the middleware on the entry point, but it will cause many issues.
Got it. Well, maybe we could think about something smart for the "rules": for example headers...we could leverage headers, so for example use CF headers to identify cloudflare, etc.
I'm completing the migration from traefik, it's not really easy since I have a pretty complete/complex configuration, entirely file based. Wasted/invested a lot of time on the security headers, since Traefik is using a go middleware called Secure to manage them, and the syntax is custom.
In case someone else has the same issue, and wants to save some time, here's the traefik header config:
default-headers:
headers:
accessControlAllowMethods:
- "GET"
- "POST"
- "PUT"
- "PATCH"
- "DELETE"
- "OPTIONS"
- "HEAD"
accessControlAllowHeaders:
- "*"
accessControlAllowOriginList:
- "*"
accessControlMaxAge: 180
addVaryHeader: true
browserXssFilter: true
contentSecurityPolicy: object-src 'self'; frame-ancestors 'self' https://*.mydomain.net;
permissionsPolicy: vibrate=(self); geolocation=(self); midi=(self); notifications=(self); push=(self); vibrate=(self); fullscreen=(self); microphone=(); camera=(); magnetometer=(); gyroscope=(); speaker=();
customFrameOptionsValue: SAMEORIGIN
hostsProxyHeaders:
- "X-Forwarded-Host"
referrerPolicy: same-origin
forceSTSHeader: true
stsIncludeSubdomains: true
stsPreload: true
stsSeconds: 63072000
And this is the equivalent, with standard headers as documented here:
entrypoint:
middlewares:
- use: ModifyResponse
set_headers:
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD
Access-Control-Allow-Headers: "*"
Access-Control-Allow-Origin: "*"
Access-Control-Max-Age: 180
Vary: "*"
X-XSS-Protection: 1; mode=block
Content-Security-Policy: object-src 'self'; frame-ancestors 'self' https://*.mydomain.net;
X-Content-Type-Options: nosniff
Permissions-Policy: vibrate=(self); geolocation=(self); midi=(self); notifications=(self); push=(self); vibrate=(self); fullscreen=(self); microphone=(); camera=(); magnetometer=(); gyroscope=(); speaker=();
X-Frame-Options: SAMEORIGIN
Referrer-Policy: same-origin
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
These set of headers have shown a great compatibility through the years, and allow to get a good score on specialized sites that analyze these things:
I'll test with godoxy once the migration from traefik is complete, hoping the results will be the same.
BTW: I had to search the repo issues to find out how to set response headers in config.yml (use: ModifyResponse), couldn't find it in the documentation. The examples I found are just for docker labels and route files, and syntax is very different.
Also for other middlewares (CloudflareRealIP, RedirectHTTP) I didn't find how to use them in config.yml entrypoint section, had to search in the issues again.
For use: oidc I found this in the docs, but it's a little bit confusing:
It documents how to use it in config.yml entrypoint, but it says NOT to use it in entrypoint. So I don't know if it will actually work or not. :)
I'll test with godoxy once the migration from traefik is complete, hoping the results will be the same.
Please let me know!
The examples I found are just for docker labels and route files, and syntax is very different.
Entry point middlewares share the same syntax with Middleware compose.
Also for other middlewares (CloudflareRealIP, RedirectHTTP) I didn't find how to use them in config.yml entrypoint section, had to search in the issues again.
Let me write the example here, playing around with UI Config Editor might give you a better explanation of the syntax.
entrypoint:
middlewares:
- use: RedirectHTTP
- use: CloudflareRealIP
- use: ModifyResponse
set_headers:
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD
Access-Control-Allow-Headers: "*"
Access-Control-Allow-Origin: "*"
Access-Control-Max-Age: 180
Vary: "*"
X-XSS-Protection: 1; mode=block
Content-Security-Policy: object-src 'self'; frame-ancestors 'self' https://*.mydomain.net;
X-Content-Type-Options: nosniff
Permissions-Policy: vibrate=(self); geolocation=(self); midi=(self); notifications=(self); push=(self); vibrate=(self); fullscreen=(self); microphone=(); camera=(); magnetometer=(); gyroscope=(); speaker=();
X-Frame-Options: SAMEORIGIN
Referrer-Policy: same-origin
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
It documents how to use it in config.yml entrypoint, but it says NOT to use it in entrypoint
It documents how to NOT use it in config.yml with an example. Foreseeable problems doing so:
- Chicken-egg problem when the IdP is being proxied by GoDoxy
- Break services that come with mobile apps
- Cannot be skipped on services with native OAuth2 support
I must say I find the UI configurator not really my cup of tea. It's not really intuitive for me, I prefer to edit directly the yaml. :)
But I have this validation error, although I copy&pasted an example configuration from the docs:
Here's the yaml code of the entire entrypoint section:
entrypoint:
middlewares:
- use: RedirectHTTP
- use: CloudflareRealIP
- use: ModifyResponse
set_headers:
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD
Access-Control-Allow-Headers: "*"
Access-Control-Allow-Origin: "*"
Access-Control-Max-Age: 180
Vary: "*"
X-XSS-Protection: 1; mode=block
Content-Security-Policy: object-src 'self'; frame-ancestors 'self' https://*.mydomain.net;
X-Content-Type-Options: nosniff
Permissions-Policy: vibrate=(self); geolocation=(self); midi=(self);
notifications=(self); push=(self); vibrate=(self); fullscreen=(self);
microphone=(); camera=(); magnetometer=(); gyroscope=(); speaker=();
X-Frame-Options: SAMEORIGIN
Referrer-Policy: same-origin
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
- use: CIDRWhitelist
allow:
- 127.0.0.1/32
- 172.16.0.0/12
- 192.168.0.0/16
- 10.0.0.0/8
- 100.0.0.0/8
status: 403
message: Forbidden
status_code: ""
access_log:
format: combined
path: /app/logs/entrypoint.log
filters:
cidr:
negative: true
values:
- 127.0.0.1/32
- 172.16.0.0/12
- 192.168.0.0/16
- 10.0.0.0/8
- 100.0.0.0/8
fields:
headers:
default: drop
config:
X-Real-Ip: keep
CF-Connecting-Ip: keep
X-Forwarded-For: keep
It documents how to NOT use it in config.yml with an example. Foreseeable problems doing so:
- Chicken-egg problem when the IdP is being proxied by GoDoxy
- Break services that come with mobile apps
- Cannot be skipped on services with native OAuth2 support
So this means OIDC has to be enabled in each container through docker labels? :(
Yes
With Traefik there's the chain middleware to logically aggregate middlewares and create a sort of "package", so users can create secure / unsecure / etc. combinations for various use-cases.
Is it something you already considered?
This was how I used it, and then easily assigned secured-auth, secured-noauth, secured-nocf to the services.
secured-auth:
chain:
middlewares:
- default-allowlist
- default-headers
- cloudflare-realip
- oidc-auth
secured-noauth:
chain:
middlewares:
- default-allowlist
- default-headers
- cloudflare-realip
secured-nocf:
chain:
middlewares:
# - default-allowlist
- default-headers
# - cloudflare-realip
@yusing is there a comparison matrix with Pangolin?
I'll offer my anecdote as i tried to set up pangolin before giving up and getting here
it doesn't let you choose which ports to use for HTTPS so if you're using it strictly as a reverse proxy and your ISP blocks those ports you're out of luck(my case)
middleware configuration is a mess, the default crowdsec install leaves you with a nonfunctional setup
one might as well utilize wireguard + any reverse proxy rather than relying on a single app to orchestrate things(for e.g since you mentioned using a hypervisor you may want to change your reverse proxy down the road for scalability)
edit: that was fast https://www.reddit.com/r/selfhosted/comments/1ke5jhy/too_soon_to_make_it_paid_pangolin/
I saw this coming, at the very first day of knowing the project existed.
- Affiliate with VPS Provider RackNerd
- Unusually Polished Marketing
- Paid YouTubers to make video about it in a very early stage
- Many bot posts and comments on reddit
- Too much initial investment: domain, fancy site, logo, business email, etc.
I saw this coming, at the very first day of knowing the project existed.
shame on them. let's make godoxy a great open-source solution so the community has the right alternative.
I'm completing the migration from traefik, it's not really easy since I have a pretty complete/complex configuration, entirely file based. Wasted/invested a lot of time on the security headers, since Traefik is using a go middleware called Secure to manage them, and the syntax is custom.
In case someone else has the same issue, and wants to save some time, here's the traefik header config:
default-headers: headers: accessControlAllowMethods: - "GET" - "POST" - "PUT" - "PATCH" - "DELETE" - "OPTIONS" - "HEAD" accessControlAllowHeaders: - "*" accessControlAllowOriginList: - "*" accessControlMaxAge: 180 addVaryHeader: true browserXssFilter: true contentSecurityPolicy: object-src 'self'; frame-ancestors 'self' https://*.mydomain.net; permissionsPolicy: vibrate=(self); geolocation=(self); midi=(self); notifications=(self); push=(self); vibrate=(self); fullscreen=(self); microphone=(); camera=(); magnetometer=(); gyroscope=(); speaker=(); customFrameOptionsValue: SAMEORIGIN hostsProxyHeaders: - "X-Forwarded-Host" referrerPolicy: same-origin forceSTSHeader: true stsIncludeSubdomains: true stsPreload: true stsSeconds: 63072000And this is the equivalent, with standard headers as documented here:
entrypoint: middlewares: - use: ModifyResponse set_headers: Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD Access-Control-Allow-Headers: "" Access-Control-Allow-Origin: "" Access-Control-Max-Age: 180 Vary: "" X-XSS-Protection: 1; mode=block Content-Security-Policy: object-src 'self'; frame-ancestors 'self' https://.mydomain.net; X-Content-Type-Options: nosniff Permissions-Policy: vibrate=(self); geolocation=(self); midi=(self); notifications=(self); push=(self); vibrate=(self); fullscreen=(self); microphone=(); camera=(); magnetometer=(); gyroscope=(); speaker=(); X-Frame-Options: SAMEORIGIN Referrer-Policy: same-origin Strict-Transport-Security: max-age=63072000; includeSubDomains; preload These set of headers have shown a great compatibility through the years, and allow to get a good score on specialized sites that analyze these things:
I'll test with godoxy once the migration from traefik is complete, hoping the results will be the same.
BTW: I had to search the repo issues to find out how to set response headers in config.yml (
use: ModifyResponse), couldn't find it in the documentation. The examples I found are just for docker labels and route files, and syntax is very different.Also for other middlewares (CloudflareRealIP, RedirectHTTP) I didn't find how to use them in config.yml entrypoint section, had to search in the issues again.
For
use: oidcI found this in the docs, but it's a little bit confusing:
It documents how to use it in config.yml entrypoint, but it says NOT to use it in entrypoint. So I don't know if it will actually work or not. :)
Hi as i am Only flying by through this projects and its issues to see if it would be an vaible fit to change on lab 1 from Traefik and lab 2 from nginx reverse proxy i saw the scan you did could you be so nice and send me the link or the site name where you did the scan i would like to see if misconfigured anything and what i would need to watchout if i test godoxy :)
Kind regards
