mengelsen

Claude Cowork offered-up (2) possible solutions for creating a bridge/integration between “Secure Passkey” and “Simple Membership”:

Path A — Flip the default filter value from FALSE to TRUE

Because Simple Membership is already listening on wp_login, the simplest possible integration is to tell Secure Passkeys to fire it. A single filter return value is enough.

add_filter(
    'secure_passkeys_web_authn_validate_user_sign_in_enable_wp_login',
    '__return_true'
);

Path B — An Explicit Bridge between the two plugins

If the site owner would rather not fire wp_login globally from the passkey flow, the same result can be achieved by hooking Secure Passkeys’s own custom action and calling the SWPM bridge directly. This is also the path to pick when there is non-trivial logic to run — for example, vetoing passkey logins for suspended Simple Membership accounts.

add_action( 'secure_passkeys_web_authn_sign_in', function ( $user ) {
    if ( ! class_exists( 'SwpmAuth' ) ) { return; }        // SWPM not loaded
    $swpm = SwpmAuth::get_instance();
    if ( $swpm->is_logged_in() ) { return; }               // already bridged
    $swpm->login_to_swpm_using_wp_user( $user );
}, 20, 1 );

As for me, I’m leaning towards Path B. An in-depth Integration report can be found here.

I also asked Claude to write a small 1-file plugin for me. It contains:

• passkey-swpm-bridge.php — a single self-contained class, Passkey_SWPM_Bridge, that hooks secure_passkeys_web_authn_sign_in at priority 20 and calls SwpmAuth::get_instance()->login_to_swpm_using_wp_user( $user ). Defensive guards cover missing dependencies (SWPM not loaded, bridge method absent, already-bridged session, non-WP_User input). A temporary $_REQUEST['rememberme'] = 1 override before the call aligns SWPM’s cookie lifetime with Secure Passkeys’ persistent wp_set_auth_cookie($user_id, true) — then properly restores the prior state in a finallyblock. Outcomes are logged via SwpmLog::log_auth_debug when available so entries land next to SWPM’s own auth events.
• readme.txt — standard WordPress plugin readme with description, requirements, installation steps, hook reference, and a short troubleshooting FAQ.

Two filters and two actions for downstream customisation:

• passkey_swpm_bridge_allow — veto the bridge for a specific user (e.g. force certain membership levels to use password login)
• passkey_swpm_bridge_rememberme — set to false for a session-only SWPM cookie
• passkey_swpm_bridge_after_bridge — fires on a successful bridge
• passkey_swpm_bridge_no_match — fires when no SWPM member exists for that email (useful for auto-provisioning a default membership)

I’m happy to send you a copy of the plugin–if you wanted to built a native bridge into Simple Membership. Or publish the plugin as a free Add-On.

The Simple Membership plugin supports content protection.
When you log into WordPress using the Simple Membership login shortcode, the user can see content, based on their membership level.

Currently, when the user logs in (using the “Login via Passkey” button) the user is authenticated to the site, but they are not able to view any of the protected content.

@mbrsolution The “Enable Auto Create Member Accounts” feature was not turned on. I toggled it on, but did not notice a difference in behavior.

The passkey still works. The user is “logged in” (can access wp-admin to edit their profile), but they cannot access protected content.

FYI: The test user that I’m adding a passkey to already exists, as WP Membership user.

I got it working. I just had to use the function exactly as it was written here: https://subscribe2.wordpress.com/support/faqs/#23

@qtwrk That’s correct. I access the CF7 form submissions via wp-admin.php.

I’m rocking WordPress v6.1.1

@hjogiupdraftplus: My test user is getting the confirmation email. (No problems there.) However, when they click the confirmation link, they are taken to a solid white page.

However, when I replace wp-login.php string with the renamed login page string, the confirmation message successfully loads.