CORS configuration not taken into account by Oauth2 client #246
-
|
Hello @ch4mpy (I'm opening another thread because this question is not directly related to the previous configuration one), I noticed that my CORS configuration doesn't seem to be taken into account by the Oauth2 client. I added the following properties in com:
c4-soft:
springaddons:
oidc:
cors:
- path: /**
allowed-origin-patterns: "http://localhost:3000"but when the front-end app is performing a back-end call, I get the following error in the browser console: I tried replacing I also tried to manually instantiate a Bean of type @Bean
fun corsFilter(addonsProperties: SpringAddonsOidcProperties): CorsFilter {
val corsProps = ArrayList(addonsProperties.cors)
return ServletConfigurationSupport.getCorsFilterBean(corsProps)
}but I still get the same error. When manually calling the endpoint directly on the back-end server, I don't see any Is there any additional configuration to add to get the CORS configuration applied ? (I saw a comment about deprecated properties at https://github.com/ch4mpy/spring-addons/blob/master/spring-addons-starter-oidc/src/main/java/com/c4_soft/springaddons/security/oidc/starter/synchronised/client/SpringAddonsOidcClientWithLoginBeans.java#L341, maybe I'm using the wrong ones ?) Thanks |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 9 replies
-
|
Request authorization in a security filter chain with This means that the browser will set the session cookie with XHR requests to the Spring backend only when these requests are sent by a page satisfying the Are you sure that you know how to send requests that are at the same time The BFF tutorial does not need cross-origin configuration because a reverse proxy makes the UI and REST API share the same origin (which ensures that these requests are
If you really want to allow
|
Beta Was this translation helpful? Give feedback.
-
|
Hello @ch4mpy,
Probably not. My understanding is that To be complete, the existing configuration manually defines a http.cors {
it.configurationSource {
CorsConfiguration().apply {
allowedOriginPatterns = listOf("http://localhost:3000")
allowedMethods = listOf(
HttpMethod.GET.name(),
HttpMethod.POST.name(),
HttpMethod.PUT.name(),
HttpMethod.DELETE.name(),
HttpMethod.OPTIONS.name()
)
allowedHeaders = listOf("*")
}
}
}so I assume the new
Yes, I'm not planning on changing the current architecture, I just want to move the Oauth2 client from front-end app to back-end app.
(I redacted the real endpoint value, I hope it's fine)
I see it's mentioning an invalid CSRF token. I tried removing the Edit: After some reading, it seems the I tried using configuration |
Beta Was this translation helpful? Give feedback.
-
What about the production base-URLs? Anyway, I tried to send a cross-origin request from a React app running on
You are already changing the architecture: moving the OAuth2 client from the front to the back end and consequently switching from Bearer-based to cookie-based request authorization. Because of that:
When simulating a call from this frontend, you have to provide a session cookie for an authorized session, and if the request is a
It would be odd to allow a
What I see there is not a CORS error, it is that the ConclusionFollow the tutorial:
|
Beta Was this translation helpful? Give feedback.
-
|
Hello @ch4mpy,
They have the same origin starting from our development environment.
OK thanks, I didn't know that. I'll try to setup a local reverse proxy.
OK thanks for confirmation. I'll update the flow to first add a GET request I think. |
Beta Was this translation helpful? Give feedback.
-
|
OK so here is what I've done so far:
I think it should work fine, as when I access the frontend app through the reverse proxy:
But then it calls the I think the issue is because the browser does not provide any After searching on internet, I tried adding Do you know if this could be related to some other configuration on the backend ? Or if something should be done on the frontend app to handle the Thanks |
Beta Was this translation helpful? Give feedback.
-
Good thing. Using your UI framework proxy for its dev server would have worked too, but if the standalone proxy you added is already configured, no need to change.
A cookie not set by the browser is most frequently due to a cross origin request. It could also be due to a request without SSL (http, not https) and a cookie flagged with You added a proxy, but do you point your browser and all redirection URIs to this proxy? As usual, I can't spot the issue without logs and configuration. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @ch4mpy,
OK. I'm confused because I thought the point of the reverse-proxy was to avoid being in a cross origin situation, but I'm probably missing something here.
I'm in
Here are the logs from backend: and from the browser console: Here are the related parts of the backend configuration: spring:
security:
oauth2:
client:
provider:
myprovider:
issuer-uri: https://xxx
registration:
myregistration:
authorization-grant-type: authorization_code
client-name: XXX
client-id: XXX
client-secret: XXX
provider: myprovider
scope: profile,other,occupation,manager,address,email,facility,roles,openid
com:
c4-soft:
springaddons:
oidc:
client:
csrf: cookie-accessible-from-js
security-matchers:
- /**
permit-all:
- /restricted/**
- /oauth2/**
- /
login-uri: /oauth2/authorization/myregistration
client-uri: http://localhost:8080
oauth2-redirections:
authentication-entry-point: unauthorized
pre-authorization-code: ok
cors:
- path: /**
allowed-origin-patterns: "http://localhost:7080"
allow-credentials: true
server:
servlet:
context-path: /api
session:
cookie:
http-only: falseFor me everything is configured to go through the proxy, except the Let me know if there are other logs/configurations that I missed that might be needed for debugging ? Thanks |
Beta Was this translation helpful? Give feedback.
-
A reverse-proxy can give the same origin only to requests that go through it...
About the The generated documentation for the Section I don't know how to be clearer than in my preceding comment and the references above: point your browser and all redirection URIs to the reverse proxy.
A session cookie should be flagged with If you can't easily update the authorization server "Valid redirect URIs" configuration, switch the BFF and proxy ports (use 7080 for the BFF and 8080 for the Nginx instance). |
Beta Was this translation helpful? Give feedback.
-
OK I'll request the new
Currently I have the XHR requests sent by
I don't think it will work, as I will also have the prefix Edit: Just tested it, and I confirm I get a Edit 2: The I have the following logs on the backend for this call: I don't understand why going through the proxy for this call is not correctly handled. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @ch4mpy, With the help of other developers, we've finally figured out what was the issue. The So adding the following configuration makes the cookie properly provided to the backend: server:
servlet:
context-path: /api
session:
cookie:
path: /backend/apiwhich is also fixing the Now I think we have a similar issue with the default I'll check how to update it with Edit: I ended up removing the above configuration, and instead handling the prefix in the # BFF
- id: backend
uri: ${bff-uri}
predicates:
- Path=${bff-prefix}/**
filters:
- StripPrefix=1
- RewriteResponseHeader=Set-Cookie, , Path=(.+), Path=${bff-prefix}$1This handles both Now I get successfully authenticated, but then I get a After debugging, I see in The configuration Edit 2: It seems the issue was also with the # BFF
- id: backend
uri: ${bff-uri}
predicates:
- Path=${bff-prefix}/**
filters:
- StripPrefix=1
- RewriteResponseHeader=Set-Cookie, JSESSIONID=(.+); Path=(.+), JSESSIONID=$1; Path=${bff-prefix}$2
- RewriteResponseHeader=Set-Cookie, XSRF-TOKEN=(.+); Path=(.+), XSRF-TOKEN=$1; Path=/ |
Beta Was this translation helpful? Give feedback.
-
|
Maybe you don't need a Note that if the production server hosts several applications, you may want to set a |
Beta Was this translation helpful? Give feedback.
-
|
Hello @ch4mpy, Thanks for feedback. I think |
Beta Was this translation helpful? Give feedback.
What about the production base-URLs?
Anyway, I tried to send a cross-origin request from a React app running on
http://localhost:3000to a stateful REST APIhttp://localhost:8080/meand Chrome did not attach theSESSIONcookie fromhttp://localhost:8080. So, no, according to Chrome,http://localhost:3000andhttp://localhost:8080do not satisfy the SameSite policy, and there is no other choice than serving the front and back ends from the same origin for requests to be authorized.You are already changing the architecture: moving the OAuth2 client from the front to the b…