Skip to content

Fix logout redirects to custom URL schemas#8402

Closed
liujed wants to merge 1 commit intoapereo:masterfrom
liujed:fix-custom-url-logout-redirects
Closed

Fix logout redirects to custom URL schemas#8402
liujed wants to merge 1 commit intoapereo:masterfrom
liujed:fix-custom-url-logout-redirects

Conversation

@liujed
Copy link
Copy Markdown

@liujed liujed commented Feb 4, 2026

Post-logout redirect URLs with custom URL schemas were incorrectly being treated as CAS-relative paths. This resulted in, for example, a redirect intended for custom://foo being sent instead to
https://localhost:8443/cas/custom://foo.

To address this, the post-logout redirect is now sent through CAS's OAuth2 callbackAuthorize endpoint, which handles custom URL schemas correctly.

Unfortunately, Puppeteer doesn't interact well with custom URL schemes:

  • When an unregistered scheme like custom:// is used, Chromium requires manual intervention to pass the URL onto Linux's xdg-open, which Puppeteer is unable to observe.
  • When a well-known scheme like mailto: is used, this leaks out into the OS's mailto handler, which Puppeteer is also unable to observe.
  • Having Puppeteer intercept an unregistered scheme isn't an option, according to how can i Intercept custom URL schemes request? puppeteer/puppeteer#9683.

This makes it challenging to write a comprehensive functional test. Instead, this PR has a negative test that checks that the custom URL scheme isn't treated as a relative path.

  • Brief description of changes applied
  • Test cases for all modified changes, where applicable
  • Any possible limitations, side effects, etc

Post-logout redirect URLs with custom URL schemas were incorrectly being
treated as CAS-relative paths. This resulted in, for example, a redirect
intended for `custom://foo` being sent instead to
`https://localhost:8443/cas/custom://foo`.

To address this, the post-logout redirect is now sent through CAS's
OAuth2 `callbackAuthorize` endpoint, which handles custom URL schemas
correctly.

Unfortunately, Puppeteer doesn't interact well with custom URL schemes:

  - When an unregistered scheme like `custom://` is used, Chromium
    requires manual intervention to pass the URL onto Linux's
    `xdg-open`, which Puppeteer is unable to observe.
  - When a well-known scheme like `mailto:` is used, this leaks out into
    the OS's `mailto` handler, which Puppeteer is also unable to
    observe.
  - Having Puppeteer intercept an unregistered scheme isn't an option,
    according to puppeteer/puppeteer#9683.

This makes it challenging to write a comprehensive functional test.
Instead, this PR has a negative test that checks that the custom URL
scheme isn't treated as a relative path.
@mmoayyed
Copy link
Copy Markdown
Member

mmoayyed commented Feb 5, 2026

Thank you for submitting this patch.

  1. This change ideally needs to be supported by Spring Webflow; ATM, external redirects are only supported by Webflow when the scheme is either http, https or some form of context/servlet relative URL. When and if spring webflow supports custom schemes, then this should work OOTB. Please contact Spring Webflow and raise this case with them before taking action here.
  2. Your puppeteer test needs to test the fact that redirect DID in fact happen; you do not need to intercept but only make sure the browser attempted to redirect to the URL given.
  3. Please do not copy puppeteer tests wholesale into a whole new test scenario without cleanup and modifications to only test the bit you care about. Or, modify an existing test to add the variation you need.

@mmoayyed mmoayyed closed this Feb 5, 2026
@liujed
Copy link
Copy Markdown
Author

liujed commented Feb 6, 2026

Thanks, Misagh. Patch submitted upstream as spring-projects/spring-webflow#1841.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants