Security form login j_spring_security_check error|j_spring_security_logout

[Mickael Lehoux]

Hello,
I'm using Geoserver cloud 1.0-RC31 and I facing a j_spring_security_check error during the connection using login form.

I found some details about
GEOSERVER_CSRF_WHITELIST
PROXY_BASE_URL

I put both .env variables in the environment directive of my gateway and webui services to try if this can help me but I'm still encountering the same error.

I'm using Caddy reverse proxy directive to redirect the public domain to the docker container.

Could you please give a little more information about where to use these .env variables or how to fix this error?

The same behavior is encountered when logout it raises j_spring_security_logout

[Gabriel Roldan]

Hi,
in gscloud we don't allow to set the proxy base url, and expect the gateway and whatever proxy is in front of it to send the appropriate X-Forwarded headers. Spring-boot takes care of it all.

As for the GEOSERVER_CSRF_WHITELIST environment variable, in docker-compose.yml you would add it to each service like this:

  wms:
    image: geoservercloud/geoserver-cloud-wms:1.0.0
    environment:
      GEOSERVER_CSRF_WHITELIST: "example.org"
  ...

if you have a sibling .env file to docker-compose.yml, where you define something like

CSRF_WHITELIST: "example.org"

then in docker-compose.yml still need to set those env variables for the containers, like in

  wms:
    image: geoservercloud/geoserver-cloud-wms:1.0.0
    environment:
      GEOSERVER_CSRF_WHITELIST: "$CSRF_WHITELIST"
  ...

[Mickael Lehoux]

Hi @groldan,

Thanks for the explanations, I'll the docker-compose environment directive tricks.

For reverse_proxy I'll go to the Caddy documentation to find something about XFH.

[Mickael Lehoux]

Hi, in gscloud we don't allow to set the proxy base url, and expect the gateway and whatever proxy is in front of it to send the appropriate X-Forwarded headers. Spring-boot takes care of it all.

I waste many hours trying to understand what is expected by spring-boot form login/logout check.

I understand there is something to do in reverse proxy configuration with X-Forwarded headers.

Could you please elaborate on your answer for a non spring-boot developer I never encountered this kind of issue before but I never doing reverse proxy for spring-boot apps.

many topic on the web return this configuration for nginx:

/...
location /geoserver {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto http;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://localhost:9090;
}
/...

An example of my reverse proxy conf in Caddyfile:

geoserver.something.io {
        tls [e-mail]
        encode zstd gzip
        reverse_proxy localhost:9090 {
                header_up Host {host}
                header_up X-Scheme {scheme}
                header_up X-Real-IP {remote_host}
                header_up Redirect off
                header_up X-Forwarded-For geoserver.something.io
                header_up X-Forwarded-Proto https
                header_up X-Forwarded-Port 443
        }
}

I'm still encountering the j_spring_security_check error and j_spring_security_logout.

[Mickael Lehoux]

I @groldan,

I'm sorry to insist, but I'm still encountering the issue about j_spring_security_check when I'm login from public https url using a reverse proxy to geoserver cloud instance.

I've test many many things but I'm still getting form action with http url instead https.

Here the gateway container env list:

Here the webui container env list:

Every solved answers talk about PROXY_BASE_URL in web.xml file

<context-param>
      <param-name>PROXY_BASE_URL</param-name>
      <param-value>https://XXXXX.XXXXXXXXXX.XXXX/geoserver</param-value>
</context-param>

or about proxy base url menu in settings > global proxy base url field

https://docs.geoserver.org/stable/en/user/configuration/globalsettings.html

but i don't have this field in my geoserver cloud docker instance:

When I edit the form action URL, from html inspector, I can login without any warning.

So my question is where can I define the form login scheme/protocol in geoserver cloud instance?

[AlexTzk]

@MkLHX did you manage to solve this? I am facing a similar issue with a private Kubernetes cluster and an externalized LB. Tried using the HTTPS_PROXYHOST env variables but didn't help. Also tried adjusting my NGINX ingress with no luck.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gateway-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/server-snippet: |
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header Host $http_host;
      proxy_set_header X-Forwarded-Proto http;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: gateway
            port:
              number: 8080

[AlexTzk]

I resolved this by exposing the service directly through nginx ingress. It's unfortunate that I can't keep the cluster private and opt for the NEG <> HTTPS LB but it is what it is.

[Mickael Lehoux]

Hi @AlexTzk
No i don't manage to use the security properly.
But i changed job since few weeks si the is on the hands of an other guy.

[prusswan]

There is an outstanding bug in regular geoserver: https://osgeo-org.atlassian.net/browse/GEOS-10158. The cloud version does not allow/support setting of PROXY_BASE_URL, making the problem worse.

Without fixing the form, I was able to get login/logout to work by using 307 instead of 301 (so the POST requests will not be downgraded to GET, see: https://serverfault.com/questions/67316/in-nginx-how-can-i-rewrite-all-http-requests-to-https-while-maintaining-sub-dom)