Security form login j_spring_security_check error|j_spring_security_logout

[MkLHX]

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

[groldan]

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"
  ...

[MkLHX]

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.

[MkLHX]

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 email@support.org
        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.

[MkLHX]

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.

[MkLHX]

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)

[aniketkr2021]

I struggled with this issue for 2–3 days. The main problem was that when enabling the GeoServer UI over HTTPS, it was throwing a j_spring_security error. After fixing the j_spring_security issue, GeoServer started loading, but key functionalities like Layer Preview, Create New Store, and Search were not working.

I followed the approach below, and everything worked perfectly. I can now access GeoServer at:
https://domain-name.com/geoserver

1. Pull the Docker image
   sudo docker pull kartoza/geoserver:2.24.2

2. Create the container
   sudo docker run --name gis_engine
   -itd
   -p 8080:8080
   -v /home/aquaGisEngineData/geo_data/:/data \ # Optional volume binding
   kartoza/geoserver:2.24.2

3. Add the following block to the Nginx server block
   (This goes inside the server block for: domain-name.com)

location /geoserver {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https; # Force HTTPS
proxy_set_header X-Forwarded-Port 443;
proxy_set_header X-Forwarded-Host $host;

proxy_buffering off;
proxy_pass http://127.0.0.1:8080/geoserver;

}
Restart Nginx after adding this.

4. Fix j_spring_security issue
   Create setenv.sh inside /usr/local/tomcat/bin with the following content:

export JAVA_OPTS="$JAVA_OPTS -DPROXY_BASE_URL=https://domain-name.com/geoserver"
export PROXY_BASE_URL=https://domain-name.com/geoserver

Make sure the file has executable permissions.

5. Update server.xml
   Edit /usr/local/tomcat/conf/server.xml and keep the same ownership and permissions as the original.
   Add the following block just under:

 <Valve className="org.apache.catalina.valves.RemoteIpValve"
   internalProxies=".*"
   remoteIpHeader="x-forwarded-for"
   proxiesHeader="x-forwarded-by"
   protocolHeader="x-forwarded-proto"
   protocolHeaderHttpsValue="https"
   httpsServerPort="443" />

6. Restart the GeoServer container

Once the above changes are complete, restart the container and access:

👉 https://domain-name.com/geoserver

Everything should now work smoothly — the UI loads correctly, and all functionalities (Layer Preview, New Store, Search, etc.) work over HTTPS.

[EBarbara]

I struggled with this issue for 2–3 days. The main problem was that when enabling the GeoServer UI over HTTPS, it was throwing a j_spring_security error. After fixing the j_spring_security issue, GeoServer started loading, but key functionalities like Layer Preview, Create New Store, and Search were not working.

I followed the approach below, and everything worked perfectly. I can now access GeoServer at: https://domain-name.com/geoserver
...
2. Create the container
sudo docker run --name gis_engine
-itd
-p 8080:8080
-v /home/aquaGisEngineData/geo_data/:/data \ # Optional volume binding
kartoza/geoserver:2.24.2
...
Everything should now work smoothly — the UI loads correctly, and all functionalities (Layer Preview, New Store, Search, etc.) work over HTTPS.

This is geoserver classic. The problem here is that these techniques don't work on geoserver cloud.