Security form login j_spring_security_check error|j_spring_security_logout
MkLHX opened this issue · 8 comments
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
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"
...
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.
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.
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?
@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
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.
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.
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)