1. Так понимаю, IPS Connect создан для этого.
IPS Connect has no central application. In an IPS Connect network, one of the applications will serve as the master, and there will be any number of slaves working off it.
When writing IPS Connect, we had three main objectives:
Single Sign-On must be completely automatic and effortless. After logging into any application in the network, the user should be automatically logged into all others. And similarly, after logging out, the same.
The process should be completely transparent to the user. The user should be able to register an account, or update account information on any application in the network, and these changes should be pushed transparently to the other applications.
It should be easy for developers to make their web applications compatible with IPS Connect - and they should be able to make their web applications serve as either the master or the slave.
So what does this mean?
As of IP.Board 3.4, it will be easy, and completely seamless to create a single sign-on network between 2 or more IP.Boards, and 3rd party developers will also be able to write support for any other web application to join in in the network.
How does it work?
For the simplicity of this example, let's say you're networking 2 IP.Board installations.
The "master" installation has a secret key which will be given the "slave" installation.
When a user visits the "slave" installation, IP.Board will check if they are logged into the "master" installation - if they are it will log them in automatically, creating the account if necessary.
If they're not logged in, but then choose to log in on the "slave" installation - they will automatically be logged into the "master" installation. This happens transparently, without the user leaving the "slave" installation.
When a user registers or updates their account, the "master" application will be pinged and updated. Again, this happens transparently.