Jump to content
bfarber
 Share


4.0 - IPS Connect

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!
 Share

Comments

Recommended Comments



:) Good to know that a ban will not effect other sites unless its ACP initiated.

 

Out of interest do warns such as mod queue (initiated on the front end) propagate ? I can see this working either way really in advantages / disadvantages. Perhaps from the ACP maybe.

Link to comment
Share on other sites

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.

 

Hmm, that's an interesting approach. How do you keep track of this process (IE where to go at each step)--is that fully managed by the master?

Link to comment
Share on other sites

 

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.

 

I don't fully understand that part.

Can I set up a new site on 4.0 as a master and still use my old site on 3.4.x  as a slave? Or do all sites need to run 4.0?

Link to comment
Share on other sites

It's good that the changes like delete or merge are being propagated to all sites now, however, there might be instances when you delete an account on a slave site and don't want the change to be propagated to the others. Is there any way to prevent the propagation?

Link to comment
Share on other sites

Lovely changes:)

 

Edit: Sorry just seen that teraßyte asked the same.

 

BUT i'm curios about the "More changes propagated" Part

 

Will this happen automatically, or will i be able to select the pages, where i want to execute this action?

e.g. user requests to be deleted/merged from site 1 (but not from site2,site3,etc..)

Link to comment
Share on other sites

I too was wondering about deletion on other site what rules are in place for posts made by the deleted user is there safeguards to prevent making swiss cheese of the threads should a user be deleted and in turn all that persons posts & replies?

Link to comment
Share on other sites

Sounds great.

 

Will it merge accounts if a user has an account on more than one site? And what happens if there is a user on the other site with the same username, or will this base off an email address?

Link to comment
Share on other sites

 

I don't fully understand that part.

Can I set up a new site on 4.0 as a master and still use my old site on 3.4.x  as a slave? Or do all sites need to run 4.0?

Think of it in terms of say the twitter API. This would truly be considered v2 of the ipsconnect 'specification', as such it's not going to be compatible with the first iteration, nor should it be due to the limitations adhering to that would impose.

At least, that's my understanding.

Link to comment
Share on other sites

Does IPS Connect support crossover domain?

you didn't read the blog post or?:D

 

 

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.

Link to comment
Share on other sites

Aaah sorry i'ts late haha. Thnx for quoting! :)

you didn't read the blog post or?:D     [b][size=5]Cross Domain Logins (and Logouts)[/size][/b]   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.

Link to comment
Share on other sites

:smile: Good to know that a ban will not effect other sites unless its ACP initiated.

 

Out of interest do warns such as mod queue (initiated on the front end) propagate ? I can see this working either way really in advantages / disadvantages. Perhaps from the ACP maybe.

 

Mod actions, including warnings, do not propagate.  IPS Connect is not intended to centralize the entire membership system - it is entirely logical a user may be "warned" on one site but that warning should not apply anywhere else.  Perhaps the user gets really irritated by discussions at site X and gets a little out of hand there, but behaves themselves just fine at the other site(s) they visit.

 

 

Hmm, that's an interesting approach. How do you keep track of this process (IE where to go at each step)--is that fully managed by the master?

 

The master keeps track of it, yes.  The details aren't all that important, unless you are intending to build another application as a master.

 

 

I don't fully understand that part.

Can I set up a new site on 4.0 as a master and still use my old site on 3.4.x  as a slave? Or do all sites need to run 4.0?

 

No. Unfortunately due to the way passwords are managed in 4.0, it is not possible to add 3.4.x to a 4.0 IPS Connect network.  We did look into it and deemed the work would reduce the security we have in place for password management in 4.0, so we opted against it.

 

It's good that the changes like delete or merge are being propagated to all sites now, however, there might be instances when you delete an account on a slave site and don't want the change to be propagated to the others. Is there any way to prevent the propagation?

 

No, but if you stop and think about it - there's no logic behind that.  If you delete a user on a slave and it DOESN'T propagate, the user can simply login again on the slave using the same credentials they've always used, and a new account would be created for them. Subsequently, there would be no real-world reason for this to actually be possible.

 

I too was wondering about deletion on other site what rules are in place for posts made by the deleted user is there safeguards to prevent making swiss cheese of the threads should a user be deleted and in turn all that persons posts & replies?

 

Similar to 3.4.x and below, when a user account is "deleted", a central routine runs through all applications and deletes their content (or updates it to be guest-submitted if appropriate).  If you delete the user, yes most of their stuff is deleted.  We are still finalizing the specific areas that will be deleted vs updates to be guest-submitted, but that's not something related to IPS Connect as it affects local account deletions regardless of whether you use IPS Connect or not.

 

Sounds great.

 

Will it merge accounts if a user has an account on more than one site? And what happens if there is a user on the other site with the same username, or will this base off an email address?

 

I am unsure what you mean.  Can you clarify? 

 

Merging does not happen across multiple sites.  Let's take a real world example - a user registers on community.invisionpower.com and posts a few threads.  They send a few private messages, ask some questions in topics, then submit a bug report.  2 months later they go to invisionpower.com and purchase a license, using a different login.  Both of these accounts are available on both installations, because they are propagated due to IPS Connect.  The user realizes what they've done and wish for their accounts to be merged.  When we merge their accounts (either at community.invisionpower.com or at invisionpower.com - it won't matter which install we use), their accounts will be merged on both installations.

 

The behavior would not be intended to allow you to merge usera@b.com from community.invisionpower.com with userc@d.com from invisionpower.com.  You would still be using the normal local "Merge Accounts" feature in the IPS software to perform the merge - the behavior discussed in this blog entry simply means that merge is carried out at all installs instead of just the one you are performing it at.

 

Is the IPS Connect network "inhouse" on our servers or do they connect with IPS Severs?

 

IPS Connect does not require our servers.  You can use IPS Connect whether your license is active or not, and all communications are directly between the servers you set up within your own network.  For example, if you own sitea.com and siteb.com, they will talk to each other directly (there is no middle man to carry out the communications).

Link to comment
Share on other sites

What about usergroup changes?

 

Would be great to "link" usergroups cross-site. Members to Members, etc. For those with paid memberships, would be great if they bought one on site A, they could be upgraded on site B via the "linked" usergroup (the group we tell the system is the same group on the other site).

 

Thanks!

Link to comment
Share on other sites




Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...