With IPBWI for WordPress v4, you will get flawless Single Sign On.

This is our current major release, available on straightvisions.com store and IPS marketplace.

How does SSO work?

IP.board brings a SSO API which allows to add several “slaves” as satellites to a “master” IP.board installation. This results in a robust single sign on solution allowing unlimited slaves even on completely different domains – same origin policy which normally breaks setting cookies for different domains has been bypassed here successfully.

Requirements

  • WordPress 4.5 or higher
  • IPcore/IP.board 4.1 or higher
  • PHP 7

How does IPBWI for WordPress exactly work?

Here’s a complete list of supported SSO cases and how IPBWI for WordPress will handle them:

IP.board

This is how SSO is fulfilled, when a SSO related action is triggered by IP.board:

Login

  • IP.board sends user to all slaves, e.g. via IPBWI for WordPress connected sites and will perform a login.
  • If there is no user account yet in WordPress, it will be created automaticly upon login.
  • If there is no IP.board account yet, login will fail, even if a corresponding WordPress account exists. IP.board account will be created upon next login through WordPress and will allow login via IP.board since then.
  • User is sent back to IP.board after all slaves have performed login action.
  • WordPress action triggered: ipbwi_sso_ipb_login

Logout

  • IP.board sends user to all slaves, e.g. via IPBWI for WordPress connected sites and will perform a logout.
  • If there is no user account yet in WordPress, it will be created automaticly upon logout.
  • User is sent back to IP.board after all slaves have performed logout action.
  • WordPress action triggered: ipbwi_sso_ipb_logout

Register

  • IP.board sends user to all slaves, e.g. via IPBWI for WordPress connected sites and will perform user account registration.
  • User is sent back to IP.board after all slaves have performed user account creation.
  • WordPress action triggered: ipbwi_sso_ipb_register

Delete

  • IP.board sends user to all slaves, e.g. via IPBWI for WordPress connected sites and will perform user account deletion.
  • For security purposes, you have to activate this feature in IPBWI for WordPress’ SSO settings explicitely.
  • You are able to globally set a target user for reassigning WordPress posts when a user is deleted via IP.board. You can find this option in IPBWI for WordPress’ SSO settings.
  • User is sent back to IP.board after all slaves have performed user account deletion.
  • WPMU: User is deleted from current blog, but not from whole network.
  • WordPress action triggered: ipbwi_sso_ipb_delete

Change Email

  • IP.board sends user to all slaves, e.g. via IPBWI for WordPress connected sites and will perform user email address change.
  • If there is no user account yet in WordPress, it will be created automaticly upon email address change attempt.
  • User is sent back to IP.board after all slaves have performed email address change action.
  • WordPress action triggered: ipbwi_sso_ipb_change_email

Change Password

  • IP.board sends user to all slaves, e.g. via IPBWI for WordPress connected sites and will perform user password change.
  • As we override WordPress’ password validation process, no password will be set in WordPress for the giving user account.
  • If there is no user account yet in WordPress, it will be created automaticly upon email address change attempt.
  • User is sent back to IP.board after all slaves have performed password change action.
  • WordPress action triggered: ipbwi_sso_ipb_change_password

Validate

  • IP.board sends user to all slaves, e.g. via IPBWI for WordPress connected sites and will perform user validation.
  • As vanilla WordPress does not have a built in validation system, like a validation group or something similar, we currently not support this feature right now.
  • If there is no user account yet in WordPress, it will be created automaticly upon validation attempt.
  • User is sent back to IP.board after all slaves have performed validation action.
  • WordPress action triggered: ipbwi_sso_ipb_validate

WordPress

This is how SSO is fulfilled, when a SSO related action is triggered by WordPress:

Login

  • WordPress performs the login
  • If there is no user account yet in WordPress, it will be created automaticly upon login.
  • Vice Versa: If there is no IP.board account yet, it will be created. This requires an existing WordPress account.
  • Redirect to master to perform login attempt on master and all slaves
  • User is sent back to WordPress after all slaves have performed login action.
  • WordPress filter available: ipbwi_sso_wp_login_destination_url

Logout

  • WordPress performs the logout
  • Redirect to master to perform logout attempt on master and all slaves
  • User is sent back to WordPress after all slaves have performed logout action.
  • WordPress filter available: ipbwi_sso_wp_logout_destination_url

Register

  • WordPress performs the registration.
  • If no corresponding IP.board account exists, it will be created.

Delete

  • WordPress performs deletion
  • For security purposes, we ban members in IP.board per default rather than delete – as this can be undone. You can enable deletion in IPBWI for WordPress’ SSO settings.

Change Email

  • WordPress changes email address of the user.
  • If corresponding IP.board account exists, e-mail address will be changed their, too.
  • Email won’t be changed if another user in WordPress or IP.board already has this address registered.

Change Password

  • WordPress changes password of the user
  • If corresponding IP.board account exists, password will be changed their, too.

Validate

  • As vanilla WordPress does not have a built in validation system, like a validation group or something similar, we currently not support this feature right now.

Customizing

We provide several action and filter hooks to allow you update-save customizing. Additionally, the powerful IPBWI-API, which is included, allows you to develop powerful extensions by your own.

Translation

We deliver IPBWI for WordPress v4 in English and German, following the WordPress standard. You can easily copy files from /wp-content/ipbwi4wp/lib/assets/lang/ and create your own language file e.g. via PoEdit. Copy the translated files into directory /wp-content/languages/ to be update save.

More Features

Member Avatars

Shows IPS Avatars in WordPress.

WordPress Network (Multi Site)

Full support for WPMU (WordPress Multi Site or WP Network)! You can decide to add new users to current blog only or to all blogs of your network.

Known Issues

IP.board

  1. This is more an IP.board issue than an IPBWI for WordPress one: While IN_DEV mode is activated in IP.board, some mechanics won’t work as expected. For example, user account deletion won’t work on IP.board site. Please deactivate DEV with removing or renaming constants.php in IP.board’s root folder for flawless SSO.
  2. While successful account validation confirmation process in IP.board for new user accounts, user is not redirected to perform SSO – that’s a conceptional bug in IPS connect. That prohibits us to synchronize loginstatus on validation process. User will be logged in within IP.board, but not in WordPress. Next time user logs into IP.board or WordPress, login status will be synced for future.
  3. Sometimes, outdated cache will result in unexpected behavior. Please empty the cache in IPS Admin CP -> System -> Support -> Something isn’t working correctly. -> Continue

WordPress

  1. AJAX driven logins via WordPress are not supported. As IPS.connect and therefor IPBWI for WordPress v4 require a redirect to perform login on all connected sites, this cannot be fulfilled by logins using ajax.