wp_cassify_get_service_callback_url() bug

  • Resolved Nagmay

    (@gabrielmcgovern)


    9 months, 3 weeks ago

    We have run into an issue with the wp_cassify_get_service_callback_url() function. Specifically, the if/else logic loor for a “redirect” parameter or a “service ticket” parameter – it does not allow both. 

    883: if ( !empty( $wp_cassify_redirect_parameter ) ) { 
         ... 
         }
    895: else if ( !empty( $wp_cassify_service_ticket_parameter ) ) { 
         ... 
         }

    For now, we have routed around the problem by applying a filter to wp_cassify_override_service_validate_url, but others are likely having the same issue.

Viewing 1 replies (of 1 total)
  • Plugin Author vbonamy

    (@vbonamy)

    8 months, 1 week ago

    Hi,

    Thanks for your report. I’ve tested the flow with redirect_to and it works as expected:

    1. Start with http://wordpress.example.org/wp-login.php?redirect_to=/sample-page/
    2. Redirected to CAS: http://cas.example.org:8080/cas/login?service=http://wordpress.example.org/sample-page/
    3. After authentication CAS returns with the ticket: http://wordpress.example.org/sample-page/?ticket=ST-xxxx
    4. Finally the user lands on http://wordpress.example.org/sample-page/ correctly authenticated.

    The if / else if logic is intentional: when building the service URL, only one parameter is relevant at a time (redirect_to before authentication, ticket after authentication). If you’re seeing different behavior, it could be due to a specific configuration or plugin conflict — could you share a concrete example URL where it fails in your setup?

    Thanks!

Viewing 1 replies (of 1 total)

The topic ‘wp_cassify_get_service_callback_url() bug’ is closed to new replies.