IPS Connect is our in-house cross-site authentication framework utilized by IP.Board in order to facilitate sharing of login credentials on one or more of your websites. While IP.Board supports Connect out of the box (meaning administrators of two or more IP.Board installations can allow users to use the same login credentials on any site in the network with just a few clicks in the ACP), the design of the system allows for third party software to tie in to the network as well. Indeed, one of the more popular addons in our Marketplace is the Wordpress IPS Connect plugin.
We have made several changes to IPS Connect in 4.0 that we believe will help you better manage a network of sites designed to share login credentials amongst them. These changes stemmed both from our own internal use of IPS Connect and from direct user feedback in our feedback forums.
Fundamental Improvements
In IP.Board 3.4, a "master" installation has no knowledge of any "slave" installations that may call to it. Any IP.Board can be set up to call to the master installation and this mater installation will never remember that the slave has called to it in the future. While this is fine for basic login credential checking, the original design of IPS Connect introduces many limitations. For instance, updating your email address on any given site cannot cause the email address to be updated on all sites because there is no central installation that knows about any of the sites in the network. Similarly, logging in to one site cannot log you in to all sites because all of the sites on the network are not actually known at any one location (we do, however, work around this if all sites are on the same domain).
Beginning with 4.0, the master installation will "register" any site that connects to it using IPS Connect. This introduces many benefits:
- If you make a change on any individual site (master or slave), that change can now be propagated to all other sites in the network.
- Logging in or out of any given site can log you in to all other sites (because all other sites are now "known")
- Requests can be queued if there are problems
- You can create a listing of all sites in the network from the master installation
Further, we have thought through potential issues and have implemented a queue system where-by if requests to an individual site in the network begin failing then those requests will be queued and reattempted at a later date in the order they were originally received. If failed requests start queuing on the master installation, an ACP dashboard block will show you this and let you attempt to process them manually. If the issue causing the requests to fail has been resolved, the queue can quickly clear out in this manner (vs waiting for the task to clear them out). If the issue is still occurring, however, you will be given some additional information which will be helpful in determining why the requests are failing. Finally, if the site in question has been taken offline and future requests should not be sent to it, you are given the opportunity to unregister the "slave" installation so that the master will no longer communicate with it.
More changes propagated
We found while using IPS Connect internally that we wanted certain actions to propagate across all sites on the network but IPS Connect did not handle this, and we subsequently had to develop custom hooks in-house to account for the missing functionality. As a result, with 4.0 IPS Connect will now manage a few additional capabilities.
Banning
As of 4.0, if you permanently ban a user from the admin control panel, the ban will be copied to the rest of the sites in the IPS Connect network. Bans are only propagated to other sites if initiated via the admin control panel as a security precaution. It is probable in many cases that you do not want moderator actions on one site affecting accounts on another site, so front-end bans will not be copied to other sites.
Deleting
As of 4.0, deleting users from one site in an IPS Connect network will now cause the user to be deleted on all sites in the network.
Merging
Similarly, as of 4.0 when you merge two users on a site in an IPS Connect network, the users will be merged on all sites in the network.
Password Changes
As of 4.0, password changes are fully propagated to all sites in an IPS Connect network. The net effect will be no different than IP.Board 3.4 in this regard, unless you later disable IPS Connect on a site in the network - in this case, the last used password will still be valid on that site, rather than some random password potentially stored on a "slave" installation 5 years ago that the user cannot remember.
Cross Domain Logins (and Logouts)
Beginning with 4.0, IPS Connect will now support logging in and out across different domains. Cookie restrictions (and the fact that the master installation did not register and/or remember any of the slave installations) prevented this capability with 3.4.x, so while the login credentials could be shared across domains, signing in to one installation did not sign you in to any other installation automatically (unless they were on the same domain). Similarly if you logged out of an installation you were not automatically logged out of any other installation in 3.4.x. As of 4.0, if you sign in to an installation (whether it is the master or an individual slave application), you will be redirected to the master installation, then redirected to each slave application in turn, and finally redirected back to your original destination. This is all very seamless to the end-user and largely unnoticeable. Logging out will, similarly, redirect you to each application to log you out of that application, bypassing security restrictions applied to cookies in a multi-domain environment.
Wrapping Up
Just as with IP.Board 3.4, other applications can tie in to the IPS Connect network, either as a master installation or as a slave installation. IPS Connect support has otherwise been greatly improved and now offers a much wider range of functionality, a more robust built-in SSO system, and more reliability when problems do occur via the new request queuing system. It should be noted that IPS Connect with 4.0 is NOT compatible with IP.Board 3.4.x, and sites will need to "re-register" with the master so that it can know about them. That minor limitation aside, we believe you will enjoy the great improvements coming in the next release!