remove cors/csrf java code configuration, in favor of regular spring-cloud-gateway configuration

[pmauduit]

Using the 2 introduced flags georchestra.gateway.corsEnabled and georchestra.gateway.csrfEnabled we can leverage default spring security behaviour related to both security measures.

Removing the cors() / csrf() .disable() calls, leaving the framework do all its own magic for us.

Note: we keep them disabled by default, as this was the default intended behaviour.
Note2: this might require a revisit to make the configuration more flexible.

Note3: With the former security-proxy, the configuration was left to the proxified webapp. If we go with this PR, we will invert the configuration and leave it to the gateway, it will then be necessary to deactivate the filters on proxified webapps, to avoid having the http response headers being set twice, which can mess up the browsers.

[groldan]

How is the CORS configuration different than the default spring-cloud-gateway way of doing so? e.g.

spring:
  cloud:
    gateway:
      globalcors:
        cors-configurations:
          '[/**]':
            allowedOrigins: "https://docs.spring.io"
            allowedMethods:
            - GET

See https://docs.spring.io/spring-cloud-gateway/reference/spring-cloud-gateway/cors-configuration.html

[pmauduit]

How is the CORS configuration different than the default spring-cloud-gateway way of doing so? e.g.

I missed that, sorry. But if we go through official yaml configuration, shall we remove the java calls to http.cors().enable()/disable() ? I am not sure which one will take precedence.

It makes totally sense to me to rely on what spring already provides anyway.

[pmauduit]

okay, stripping the http.cors().csrf() java configuration runtime-tested with the following config locally:

spring:
  cloud:
    gateway:
      globalcors:
        cors-configurations:
          '[/**]':
            allowedOrigins: "*"
            allowedHeaders: "*"
            allowedMethods: "*"

The following curl payload returns indeed a 200 - ok:

 curl 'http://localhost:8080/geonetwork/srv/api/search/records/_search?bucket=bucket' \                                                    2023-10-18 17:55:48 pmauduit pts/7
  -X 'OPTIONS' \
  -H 'authority: localhost:8080' \
  -H 'accept: */*' \
  -H 'accept-language: en-US,en;q=0.9,fr;q=0.8,de;q=0.7' \
  -H 'access-control-request-headers: content-type' \
  -H 'access-control-request-method: POST' \
  -H 'origin: https://dev.datagrandest.fr' \
  -H 'referer: https://dev.datagrandest.fr/' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: cross-site' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36' \
  --compressed -i
HTTP/1.1 200 OK
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: content-type
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1 ; mode=block
Referrer-Policy: no-referrer
content-length: 0

Funny thing is that if I revert my java modification, the configuration stays valid and I am able to get "200 - OK" status, without touching the Java code (which does not really make sense, because with http.csrf().disabled().cors.disabled() I'd have expected it to be disabled.

@groldan does removing the related Java code make sense to you ? As we can use the yaml configuration anyway.

[groldan]

LGTM