I am implementing a way for different domains to share their data between themselves without needing to replicate the database backends.
The architechture that I have so far been able to think of is as follows:
federation_servers table
ID, FriendlyName, ServerAddress, APIVersion, SharedKeyRemote, SharedKeyLocal
ID: The Local ID of the Federated Server.
FriendlyName: The Display Name for the Federated Server.
ServerAddress: The Address to the server that is being federated.
APIVersion: The Version of the API being used, Min is v2, v1 is not going to be supported.
SharedKeyRemote: The Federation API Shared Key to be used to connect from the local server to the remote server.
SharedKeyLocal: The Shared API Key for the remote server to connect to us. This is unique per federation connection.
There will eventually be support on all three levels of the code; HTML, API, and CLI
Right now I am working on the HTML and API versions, but support for CLI should be as easy as adding the new class to the code in the cli.
The HTML will have a page that starts the Federation query where you can select the server you want to browse. Once you select the server you will be asked what type of query you want to do. You can choose between: AP's, Users, or Imports.
The HTML view will use the API, so the API will have the same queries, but more detail at some levels that will be hidden by the HTML front-end to make it more "User friendly view-able"
The SharedKeys are only only for the queries between the servers, a user that is using the API will still need to have an authentication key of their own to authenticate to the local server that they are connecting too's API.
That is all I have for now, as I do think of something, I will post a comment with an update.
-Phil
I am implementing a way for different domains to share their data between themselves without needing to replicate the database backends.
The architechture that I have so far been able to think of is as follows:
federation_servers table
ID, FriendlyName, ServerAddress, APIVersion, SharedKeyRemote, SharedKeyLocal
ID: The Local ID of the Federated Server.
FriendlyName: The Display Name for the Federated Server.
ServerAddress: The Address to the server that is being federated.
APIVersion: The Version of the API being used, Min is v2, v1 is not going to be supported.
SharedKeyRemote: The Federation API Shared Key to be used to connect from the local server to the remote server.
SharedKeyLocal: The Shared API Key for the remote server to connect to us. This is unique per federation connection.
There will eventually be support on all three levels of the code; HTML, API, and CLI
Right now I am working on the HTML and API versions, but support for CLI should be as easy as adding the new class to the code in the cli.
The HTML will have a page that starts the Federation query where you can select the server you want to browse. Once you select the server you will be asked what type of query you want to do. You can choose between: AP's, Users, or Imports.
The HTML view will use the API, so the API will have the same queries, but more detail at some levels that will be hidden by the HTML front-end to make it more "User friendly view-able"
The SharedKeys are only only for the queries between the servers, a user that is using the API will still need to have an authentication key of their own to authenticate to the local server that they are connecting too's API.
That is all I have for now, as I do think of something, I will post a comment with an update.
-Phil