Fix bug in certain error handling for authorize endpoint when response_mode=form_post is requested #1179
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When response_mode=form_post is requested, some error cases will be returned to the client using the form_post web page to POST the result back to the client's redirect URL. However, the authorize endpoint was not setting the form_post page's CSP headers on its responses, so the browser would refuse to run the page's Javascript code to POST the error message back to the client's redirect URL. This broke the flow for certain error messages that were supposed to be shown to the user by the client, but instead the user would be left looking at a blank web page and a client still waiting for a callback to happen.
This was not caught by integration tests because it is very hard to write an integration test for any of these errors at the authorization endpoint. The e2e integration test covers using the CLI with form_post mode, however the CLI will never create the types of malformed requests which would demonstrate these errors which get returned by the authorize endpoint using the form_post page. The kinds of errors that would be easy to cause in a test (e.g. by purposefully misconfiguring an OIDCIdentityProvider) are all handled by the callback endpoint, which did not suffer from this same CSP headers bug.
Release note: