Skip to content

Fix logout redirects to custom URL schemas#8403

Closed
liujed wants to merge 1 commit into
apereo:7.3.xfrom
liujed:fix-custom-url-logout-redirects-7.3.x
Closed

Fix logout redirects to custom URL schemas#8403
liujed wants to merge 1 commit into
apereo:7.3.xfrom
liujed:fix-custom-url-logout-redirects-7.3.x

Conversation

@liujed

@liujed liujed commented Feb 4, 2026

Copy link
Copy Markdown

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
  • The same pull request targeted at the master branch, if applicable
  • Any possible limitations, side effects, etc

master: #8402

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.
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