Adding support for custom CORS preflight Access-Control-Allow-Headers response
1,316 views
Skip to first unread message
Ben Leggett
unread,
Jun 2, 2021, 7:40:44 PM6/2/21
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to keyclo...@googlegroups.com
Hey all -
We're using Keycloak with a custom protocol mapper that performs an optional operation (adding custom claims, etc) if a custom header (e.g. 'X-CustomHeader: foo') is sent with the OIDC request.
Unfortunately this doesn't work in a browser context, because Keycloak's CORS preflight response isn't aware of the custom header and doesn't include it in the Access-Control-Allow-Headers header it sends as a preflight response back to the client, so any clients that do preflight requests assume Keycloak doesn't accept the header, and drop the request.
It seems as if it would be relatively easy to allow that list to be extended as part of Keycloak config, so that Keycloak could be configured to inform clients that they are allowed to send other headers - are there any objections to a PR making this configurable?
Thanks!
Ben
Ben Leggett
unread,
Jun 3, 2021, 3:37:25 PM6/3/21
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
I don't see any significant obstacles to exposing `Access-Control-Allow-Headers` as a server configuration the same way Keycloak currently does for `Access-Control-Allow-Origin`, and will begin work on a PR within the next few days.
Stian Thorgersen
unread,
Jun 7, 2021, 7:48:26 AM6/7/21
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Ben Leggett, Keycloak Dev
Can you describe what you plan to do here? We are actually moving away from the static list of key->value headers that can currently be set in the realm.
If work is already planned to correct that, then that's great.
My goal was to make that currently-hardcoded and fixed list of headers optionally configurable, enabling browser clients to send additional headers beyond what's listed there.
Access-Control-Allow-Headers is a pure allowlist, and as far as I can tell there's no reason why it shouldn't be a user-configurable allowlist.