kirkyedinak

Thanks for suggestion the filter. The getSessionIndex() and getNameId() calls where throwing errors. That got me digging around a bit more and I found wp_saml_auth_attributes.

I ended up using this filter:

add_filter(
	'wp_saml_auth_attributes',
	function ( $attributes, $provider ) {
		session_start();
		$_SESSION['sessionIndex'] = $provider->getSessionIndex();  
		$_SESSION['nameId'] = $provider->getNameId();
		return $attributes;
	}, 10, 2 );

The provider array holds a ton of useful information. A user should look there if they need any other information returned from the authentication.

To include both the NameID and SessionIndex in the logout request you could make this change. In your class-wp-saml-auth.php file, I modified do_saml_authentication().

I added the following code at line 259

session_start();
$_SESSION['sessionIndex'] = $provider->getSessionIndex();
$_SESSION['nameId'] = $provider->getNameId();

My filter function now looks like this:

function wpsax_filter_internal_logout_args( $args ) {
    session_start();
    $args['nameId']         = $_SESSION['nameId'];
    $args['sessionIndex']   = $_SESSION['sessionIndex'];
    return $args;
}

I now receive a status:Success in the LogoutResponse.

Thanks for the link to auth0 documentation. That got me thinking…

In your class-wp-saml-auth.php file, I modified do_saml_authentication().

I added the following code at line 259

session_start();
$_SESSION['sessionIndex'] = $provider->getSessionIndex();

My filter function now looks like this:

function wpsax_filter_internal_logout_args( $args ) {
    session_start();
    $args['sessionIndex']  = $_SESSION['sessionIndex'];
    return $args;
}

The SessionIndex is captured from the login response and stored in a session variable and is now included in the logout request.

If you find a better solution, please let me know.

Here is my filter function. The logout status is being reported with: Session index is not valid

function wpsax_filter_internal_logout_args( $args ) {
    session_start();
    $args['nameId']     = '[email protected]';
    $args['sessionIndex']  = session_id();
    return $args;
}

How do I properly get the Session Index?

@danielbachhuber thanks for the quick reply. I’ve modified the action_wp_logout function with your proposed changes, and I’ve ensured my singleLogoutService url is set. Unfortunately the only change in the logout request that I see is in the RelayState. The logout request remained as it was in my previous post.

SimpleSAMLphp is reporting the following:
Unsuccessful logout. Status was: SimpleSAML\Module\saml\Error: Requester

This is most likely due to the missing Session Index.

My apologies if I’m missing something here.

After selecting the Page caching method Opcode: WinCache I was able to get the option Maximum lifetime of cached objects in the Advanced section of Performance -> Page Cache. I set the value of that option from 3600 to 86400. I then changed the page caching method back to Disk Basic.

Now the script (Cache_File_Cleaner.php) reports the same expiration date as the expiration date in the header.

I’m was using Disk Basic for page caching. I have changed to OpCode WinCache since I’m on a windows server. Hopefully this will resolve the issue.

@donncha I apologize for the delay in responding. I have enabled Debug and found nothing interesting in the error log file. Here are some debug data from the log file when searching for ‘glider’.

18:50:30 35228 /?s=glider wp_cache_get_cookies_values: return:
18:50:30 35228 /?s=glider wp_cache_get_cookies_values: return:
18:50:30 35228 /?s=glider wp_cache_check_mobile: bogusdomainname.com443/?s=glidergzip
18:50:30 35228 /?s=glider supercache dir: D:\home\site\wwwroot\wp-content/cache/supercache/bogusdomainname.com/
18:50:30 35228 /?s=glider wp-cache file exists: D:\home\site\wwwroot\wp-content/cache/supercache/bogusdomainname.com/wp-cache-42fb3ca404a49bca9b97cf50b754349e.php
18:50:30 35228 /?s=glider Serving wp-cache static file
18:50:30 35228 /?s=glider exit request

What I find interesting is the file ‘D:\home\site\wwwroot\wp-content/cache/supercache/bogusdomainname.com/wp-cache-42fb3ca404a49bca9b97cf50b754349e.php’ listed as existing in the log, actual does not exist. However a file with a similar name does exist: ‘D:\home\site\wwwroot\wp-content/cache/supercache/bogusdomainname.com/meta-wp-cache-42fb3ca404a49bca9b97cf50b754349e.php’

The content of the meta-wp-cache file is the following:
<?php die(); ?>{"headers":{"Content-Encoding":"Content-Encoding: gzip","Vary":"Vary: Accept-Encoding, Cookie","Last-Modified":"Last-Modified: Tue, 16 Jan 2018 18:07:49 GMT","Content-Type":"Content-Type: text\/html; charset=\"UTF-8\""},"uri":"bogusdomainname.com\/?s=glider","blog_id":1,"post":0,"key":"bogusdomainname.com443\/?s=glidergzip"}

Were you able to resolve this issue? I’m experiencing the same problem. I did notice in the meta-wp-cache-xxxx.php files, they all start with <?php die(); ?> followed by the json encoded string. If I remove <?php die(); ?> from that file, the page will load (not very quickly, but it will load). I’m curious to know why the die code is in these files.