Setting up reverse proxy with Caddy, jwt and login with auth site

Hey y’all! Thanks for an awesome product!
I’m trying to get Caddy, jwt and login to work together to authorize access to my reverse proxy setup, but I’m having difficulty (most likely due to my noobish ways). The browser’s console clearly has my token and I’ve validated it at jwt.io containing relevant data.
My problem; I’m visiting home.domain.tld, and I’m redirected to auth.domain.tld. All good so far. But as soon as I’ve authenticated with Google, I’m returned to the login page asking me to login again. I’m not redirected back to the original home site with access to its data.
OS: FreeBSD 11.2-STABLE #0 r325575+fc3d65faae6(freenas/11.2-stable)
Arch: amd64
Version: Caddy 0.11.3
Caddyfile:

(g-auth) {
        jwt {
                path /
                redirect https://auth.domain.tld/login?backTo=https://{host}{rewrite_uri}
                allow domain domain.tld
        }
}
auth.domain.tld {
        redir 302 {
                if {path} is /
                / /login
        }

        gzip
        root /usr/local/www/auth.domain.tld/
        log /var/log/auth.domain.tld/access.log

        login {
                success_url https://{host}{rewrite_uri}
                google client_id={$GOOGLE_CLIENT_ID},client_secret={$GOOGLE_CLIENT_SECRET}
                cookie_domain domain.tld
                redirect_check_referer false
                redirect_host_file /usr/local/www/auth.domain.tld/redirect_hosts.txt
                template login.html
        }
}

home.domain.tld {
        import g-auth
        gzip
        root /usr/local/www/home.domain.tld/
}

Anyone know what’s wrong? Thanks in advance!

I havent uses the login directive, but it seems to me that you’re asking it to return back to auth.domain.tld on success.

Perhaps you need a differnt success_url

Heya,
Thanks for your reply! I’ve tried hard-coding a value as well as tried it empty or a bogus URL, but success_url doesn’t seem to be honored (or make any difference at all), so I’m quite confident my problems aren’t (directly) related to that flag, but I’m happily proven wrong :stuck_out_tongue:

Yeah, success_url is only used when there’s no ?backTo= query. The latter overrides the former.

I’ve got a similar setup. I tried it over subdomains (i.e. login.whitestrake.net) but ended up consolidating on a single subdomain - not because it didn’t work (it did work for me across subdomains) but as a matter of preference.

Here’s my Caddyfile as it stands right now.

Caddyfile
(secure) {
  jwt {
    path /
    redirect /login?backTo={uri}
  }
}

sub.example.com {
  root /dev/null
  gzip

  # Heimdall
  jwt /settings
  jwt /items
  jwt /tags
  proxy /css/app.css heimdall
  proxy / heimdall {
    transparent
  }

  # Netdata
  redir /netdata /netdata/
  proxy /netdata netdata:19999 {
    without /netdata
  }
  proxy /css netdata:19999
  proxy /lib netdata:19999
  proxy /api netdata:19999
  proxy /dashboard netdata:19999

  # Guacamole
  redir /guacamole /guacamole/
  proxy /guacamole guacamole:8080 {
    transparent
    websocket
  }

  # Loginsrv
  login {
    login_path /login
    logout_url sub.example.com
    redirect_check_referer false
    cookie_domain example.com
    htpasswd file=/etc/.htpasswd
    jwt_expiry 12h
  }

  proxy /sync torrents:3000
}

sub.example.com/torrents {
  import secure
  redir {
    if {path} is /torrents
    / /torrents/
  }
  proxy / torrents:3000
}

sub.example.com/sonarr {
  import secure
  proxy / sonarr:8989/sonarr
}

sub.example.com/radarr {
  import secure
  proxy / radarr:7878/radarr
}

sub.example.com/nzbget {
  import secure
  proxy / nzbget:6789/nzbget
}

sub.example.com/hydra {
  import secure
  proxy / hydra:5075/hydra
}

I can’t see what would be going wrong based on the config I’m reading in your post, but the only general advice I can give is to simplify until you can get it working, then start adding in complexity again. Try doing it on a single subdomain first.

1 Like

Hmm, OK …
Thanks for your help, both of you, it seems I had royally screwed my login template which seems to have been the cause. After reverting to a previous version of that, things started rolling again.
@Whitestrake: Your comment about simplifying nudged me in the right direction, thanks!
Take care, y’all …

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.