-
|
Hi, I'm using spring-addons-starter-oidc along with Spring Cloud Gateway to implement the BFF pattern with a Spring Boot module. This allows me to manage SSO for a legacy web application based on JSP and JavaScript. My BFF uses Spring Boot 3.3.6 and spring-addons-starter-oidc version 7.8.12. I'm trying to upgrade to the new version 8.1.0 to take advantage of the new back-channel logout functionality (also upgrading Spring Boot to 3.4.2 and spring-cloud-dependencies to 2024.0.0), but I'm getting the classic Invalid CSRF Token error. Yet nothing has changed, and my POST calls continue to send the correct x-xsrf-token value in the request headers to the BFF application. What is changed ? I tried to figure out from ServletConfigurationSupport.java and in particular the SpaCsrfTokenRequestHandler method, but I could not find a solution.. Thank you very much for the help! |
Beta Was this translation helpful? Give feedback.
Replies: 8 comments 13 replies
-
|
Hi, It seems that Spring Security's default configuration has evolved and does not work anymore for server-side rendered applications. As I don't personally write such apps, I didn't notice, but I could reproduce your issue with the logout on the resource-server_with_ui tutorial (logout currently fails because of a CORS error). As one of the aims of If you can't wait for a fix, you may try using the "cookie" CSRF repo (set the You can also expose a |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, I will try to write a custom version of the ClientSynchronizedHttpSecurityPostProcessor bean. Just to point out, my BFF application is already using the csrf: 'cookie-accessible-from-js' option with version 3.3.6 of spring-boot-starter and 7.8.12 of spring-addons-starter-oidc and the javascript on the JSP pages of my legacy application already reads the XSRF-TOKEN cookie and sets the X-XSRF-TOKEN header. With this configuration, I have no 'CSRF Invalid Token' problems. The problem arises with spring-boot-starter 3.4.2 (and spring-addons-starter-oidc 8.1.0) , where I am using this configuration: com:
c4-soft:
springaddons:
oidc:
ops:
- iss: ${issuer}
username-claim: ${username-claim-json-path}
authorities:
- path: ${authorities-json-path}
client:
client-uri: ${client-uri}
back-channel-logout:
enabled: true
internal-logout-uri: ${client-uri}/logout/connect/back-channel/dt1-bff-client
security-matchers:
- /**
permit-all:
- /login/**
- /oauth2/**
- /actuator/**
csrf: cookie-accessible-from-js
oauth2-redirections:
rp-initiated-logout: ACCEPTED |
Beta Was this translation helpful? Give feedback.
-
|
With a server-side rendered application (like your JSP, but it's the same with JSF, Thymeleaf, etc.), the session repo should be fine and you shouldn't need to expose the CSRF token to Javascript. But knowing that you are using a mechanism that still works with SPAs is useful. Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
I could finally get a
For that, I had to change from: <form method="POST" action="/logout">
<button type="submit">Logout</button>
</formto: <form method="POST" action="@{/logout}">
<button type="submit">Logout</button>
</formApparently, the fact that the action is interpolated is now required for the default CSRF token handler to hook in the form submission handling. Can you think of something similar in the processing of JSPs? Can you share a reproducer with JSPs, cookie CSRF token repo, and the Javascript to read the cookie and set the header? |
Beta Was this translation helpful? Give feedback.
-
|
Excuse me, But what is the difference between using POST calls made in my JSP pages hardly ever start from forms. But they are almost exclusively xhr calls with JQuery similar to this: function getCookie(name) {
var value = ”; ” + document.cookie;
var parts = value.split(“; ‘ + name + ’=”);
if (parts.length == 2) return parts.pop().split(“;”).shift();
}
const xsrf = getCookie('XSRF-TOKEN');
$.ajax({
url : “/test/getMap”,
headers : {
“Content-Type” : “application/json”,
“Accept” : ‘application/json’,
"X-XSRF-TOKEN" : xsrf
},
type : “POST”,
async : false,
success : function(data) {
map = data.map;
....
},
error : function(jqXHR, textStatus, errorThrown) {
......
}
});I don't have much time today, but as soon as I can, I will try to share you a working example on GitHub to test this problem Thank you for support! |
Beta Was this translation helpful? Give feedback.
-
|
With With As you are using JQuery to send XHR requests, you have to use the 2nd option. If you were using forms with |
Beta Was this translation helpful? Give feedback.
-
|
I got the
com:
c4-soft:
springaddons:
oidc:
ops:
client:
csrf: cookie-accessible-from-js
oauth2-redirections:
rp-initiated-logout: accepted
<!DOCTYPE HTML>
<html xmlns:th="http://www.thymeleaf.org">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<meta name="description" content="">
<meta name="author" content="">
<title>Greetings!</title>
<link href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta/css/bootstrap.min.css" rel="stylesheet"
integrity="sha384-/Y6pD6FV/Vv2HJnA6t+vslU6fwYXjCFtcEpHbNJ0lyAFsXTsjBbfaDjzALeQsN6M" crossorigin="anonymous">
<link href="https://getbootstrap.com/docs/4.0/examples/signin/signin.css" rel="stylesheet"
crossorigin="anonymous" />
</head>
<body>
<div class="container">
<h1 class="form-signin-heading">Greetings from the REST API</h1>
<div th:utext="${greeting}">..!..</div>
<button type="submit" th:onclick="logout()">Logout with Javascript</button>
</div>
<script th:inline="javascript">
function getCsrfToken() {
var parts = document.cookie.split("XSRF-TOKEN=");
if (parts.length == 2) {
return parts.pop().split(";").shift();
}
}
function logout() {
$.ajax({
url: "/logout",
headers: {
"X-XSRF-TOKEN": getCsrfToken()
},
type: "POST",
async: false,
success: function (data, textStatus, response) {
const rpInitiatedLogoutLocation = response.getResponseHeader('location');
window.location = rpInitiatedLogoutLocation;
},
error: function (jqXHR, textStatus, errorThrown) {
console.log(textStatus, errorThrown)
}
});
}
</script>
<script src="https://code.jquery.com/jquery-3.7.1.min.js"></script>
</body>These tests have shown some issues with the invalid session strategy introduced in |
Beta Was this translation helpful? Give feedback.
-
|
The invalid session strategy is fixed in The default profile uses the session CSRF repo. The The |
Beta Was this translation helpful? Give feedback.
-
|
Hello, You were really quick! Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
You can also |
Beta Was this translation helpful? Give feedback.
-
|
No.. the problem is still there. I'm using the “javascript” profile, but if it only served to set I am attaching my current configuration. Meanwhile, I will try to pinpoint the section in the code where the check that generates the error occurs. client-uri: https://dt1.lan
bivdt-uri: http://dt1.wf26.lan:8080
bav-uri: http://dt1.wf26.lan:8080
issuer: https://auth.lan/realms/autostrade
client-id: dt1-bff-client
client-secret:
username-claim-json-path: $.preferred_username
authorities-json-path: $.realm_access.roles
server:
port: 7443
ssl:
bundle: "web-server"
http2:
enabled: true
compression:
enabled: true
servlet:
session:
timeout: 10m
spring:
profiles:
active: javascript
threads:
virtual:
enabled: true
web:
resources:
static-locations: 'classpath:/static/'
ssl:
bundle:
pem:
web-server:
keystore:
certificate: 'file:/opt/bff.crt'
private-key: 'file:/opt/bff.key'
cloud:
gateway:
default-filters:
- DedupeResponseHeader=Access-Control-Allow-Credentials Access-Control-Allow-Origin
routes:
- id: bivdt
uri: ${bivdt-uri}
predicates:
- Path=/BIVDT/**
filters:
- StripPrefix=1
- id: bav
uri: ${bav-uri}
predicates:
- Path=/BAV/**
filters:
- StripPrefix=1
security:
oauth2:
client:
provider:
keycloak:
issuer-uri: ${issuer}
user-name-attribute: preferred_username
registration:
dt1-bff-client:
provider: keycloak
authorization-grant-type: authorization_code
client-id: ${client-id}
client-secret: ${client-secret}
scope:
- openid
- profile
- roles
#- offline_access
com:
c4-soft:
springaddons:
oidc:
ops:
- iss: ${issuer}
username-claim: ${username-claim-json-path}
authorities:
- path: ${authorities-json-path}
client:
client-uri: ${client-uri}
#login-uri: /BIVDT-login
back-channel-logout:
enabled: true
internal-logout-uri: ${client-uri}/logout/connect/back-channel/dt1-bff-client
security-matchers:
- /**
permit-all:
- /login/**
- /oauth2/**
- /actuator/**
csrf: cookie-accessible-from-js
oauth2-redirections:
rp-initiated-logout: accepted
#post-logout-redirect-path: /BIVDT-login
logging:
level:
org:
springframework:
security: DEBUG
cloud: DEBUG
|
Beta Was this translation helpful? Give feedback.
-
No, it also changes:
I updated the The CSRF protection with |
Beta Was this translation helpful? Give feedback.
-
|
What are the details of your failing request (URI, headers, cookies) and what are the Security TRACE logs in the Spring apps? |
Beta Was this translation helpful? Give feedback.
-
|
Ok, My BFF's application.yaml is the one I attached above, and its code is limited to the bare minimum without customizations (SpringBootApplication). The javascript code is almost identical to the the one I attached above.. This is an example of a call that generates the error: TRACE (logging.level.org.springframework: TRACE) REQUEST RESPONSE COOKIES 192.168.90.x internal subnet docker compose (expose NGINX with port 843) |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure about your architecture. Where are the JSPs hosted? On a dedicated server or on the Gateway itself? Also, could you try the servlet version of the Gateway ( cloud:
gateway:
default-filters:
- DedupeResponseHeader=Access-Control-Allow-Credentials Access-Control-Allow-Origin
mvc:
routes:
- id: bivdt
uri: ${bivdt-uri}
predicates:
- Path=/BIVDT/**
filters:
- StripPrefix=1
- id: bav
uri: ${bav-uri}
predicates:
- Path=/BAV/**
filters:
- StripPrefix=1 |
Beta Was this translation helpful? Give feedback.
-
|
The JSPs are inside multiple wars deployed in a Wildfly 26 |
Beta Was this translation helpful? Give feedback.
-
|
it works! thank you But this version is not reactive.. what are the differences ? |
Beta Was this translation helpful? Give feedback.
-
|
I'm trying to figure out what's going on. I am using remote debugging.. Maybe it can help you. Inside CsrfWebFilter class the method containsValidCsrfToken returns false. because inside interface ServerCsrfTokenRequestHandler the method resolveCsrfTokenValue seem to return nothing (empty Mono.) |
Beta Was this translation helpful? Give feedback.
-
|
In the meantime, I was trying with a Reactive Gateway hosting a Thymeleaf template with some XHR and could reproduce your error. The spring-addons auto-configuration for CSRF protection with I just published
The
Because of their non-blocking model, WebFlux applications were supposed to save resources in massively multi-threaded applications. This is why Spring Cloud initially designed its Gateway around it. However, with Java 21 and virtual threads, this benefit vanished. As synchronized applications (like servlets) are much easier to debug, I now only use
The component I restored and auto-configure with If debugging with If keeping @Configuration
public class SecurityConfig {
@Bean
ClientReactiveHttpSecurityPostProcessor clientReactiveHttpSecurityPostProcessor() {
return (ServerHttpSecurity serverHttpSecurity) -> {
return serverHttpSecurity.csrf(csrf -> {
csrf.csrfTokenRepository(CookieServerCsrfTokenRepository.withHttpOnlyFalse())
.csrfTokenRequestHandler(new SpaCsrfTokenRequestHandler());
});
};
}
static final class SpaCsrfTokenRequestHandler extends ServerCsrfTokenRequestAttributeHandler {
private final ServerCsrfTokenRequestAttributeHandler delegate =
new XorServerCsrfTokenRequestAttributeHandler();
@Override
public void handle(ServerWebExchange exchange, Mono<CsrfToken> csrfToken) {
this.delegate.handle(exchange, csrfToken);
}
@Override
public Mono<String> resolveCsrfTokenValue(ServerWebExchange exchange, CsrfToken csrfToken) {
return Mono
.justOrEmpty(exchange.getRequest().getHeaders().getFirst(csrfToken.getHeaderName()))
.switchIfEmpty(this.delegate.resolveCsrfTokenValue(exchange, csrfToken));
}
}
}Be really careful with the |
Beta Was this translation helpful? Give feedback.
-
|
Closing as this actually is a bug report that has no value being listed in Q&A (not a problem that another user could face later on) |
Beta Was this translation helpful? Give feedback.
-
|
Closing as this actually is a bug report that has no value being listed in Q&A (not a problem that another user could face later on) |
Beta Was this translation helpful? Give feedback.
In the meantime, I was trying with a Reactive Gateway hosting a Thymeleaf template with some XHR and could reproduce your error.
The spring-addons auto-configuration for CSRF protection with
HttpOnly=falsehas been broken in reactive applications since version8.1.0. The problem is that I blindly trusted the Spring Security docs for that and removed the customServerCsrfTokenRequestAttributeHandler. As I used only servlet Gateways, I didn't notice that the doc is wrong for reactive apps :/I just published
8.1.2with a fix. I also added two BFF samples which contain Thymeleaf templates with XHR requests: