Slave IPS Connect applications will need to send requests for specific actions via an HTTP REST API call to the IPS Connect master installation. This means that you will need to obtain the URL and API key from your IPS Connect master installation and supply this to your slave application, and then when a user attempts to perform one of the actions outlined at the top of this article your login routines should make API calls to the master application in order to perform and validate those actions. Be aware: Some requests result in redirecting the user to one or more websites before returning the user to a URL you supply. See the crossLogin method outlined below for an example. For most requests, however, you will receive a JSON response which will need to be decoded and examined.
If you issue a login request, for instance, you will receive a response with a status code and then some additional information such as the email address, username and unique ID on the network. Most slave applications will then create a local user record with this data if the user account does not exist, or update the local user record if the account does exist (using the unique ID to match up user accounts if possible, or falling back to matching accounts by email address). This is not, however, a requirement.
Note: After making a login request to the master installation, an IPS Connect slave should then call the crossLogin request at the master installation in order to ensure the user is logged in to all websites in the IPS Connect network. This method will result in the user being redirected to all installations in the network, and then finally back to a URL supplied by the local slave application.
All account changes must be sent to the master installation to ensure data consistency across the network. If a user changes their email address and this account change is not sent to the master application, for instance, the user will no longer be able to login correctly on other sites in the network.
Additionally, all slave applications must accept the same requests and respond accordingly just as the master would, as the master application must propagate requests to each slave in the network. For instance, consider the following work flow:
User changes their email address on SLAVE 1. SLAVE 1 sends this request to the MASTER. The MASTER, in turn, sends the request to SLAVE 2 and then to SLAVE 3. In this case, even though SLAVE 2 and SLAVE 3 are slave applications, they must accept the same requests the master accepted in order to allow them to update their local databases.
Report Document