You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current architecture of live.ts is based on two main actors: the Admin and the Tenant Site, which are separate deployments. The Admin UI is responsible for writing into the configuration database, while the Tenant Site handles the read operations. However, this approach can lead to inconsistencies and limitations when dealing with configuration changes (releases). This proposal aims to address these challenges by introducing a new approach to handle configuration changes in live.ts.
Below you can see an oversimplified version of the current architecture.
Background
In the current implementation, the Admin UI is responsible for writing configuration changes into the database, and releases are published as encapsulated blobs of configurations distributed across site deployments. However, relying solely on the Admin for writing and the Site for reading can lead to inconsistencies and limitations in managing configuration changes.
Problem 1: Inconsistency in Data Store Providers
The Admin UI manages multiple sites, making it challenging to handle different data store providers for each site. Storing this information within the Site deployment offers more flexibility and autonomy for each site to define its own data store infrastructure.
Problem 2: Validation and Open Source Flexibility
Allowing the Site deployment to validate against the current JSONSchema state offers greater control and flexibility. It also enables the possibility of creating a fully open-source version where the database can be switched to the user's file system, providing alternative storage options.
Problem 3: Authorization and Cross-Deployment Access
Enabling the Site deployment to have specific authorization keys allows for more secure and granular control over data storage. For example, in the case of running on Deno, Deno KV can be inaccessible for cross read/write operations between the Admin deployment and the Site Deno KV deployment.
Detailed Design
To address the challenges mentioned above, this proposal suggests the following changes to live.ts:
Authorized Write API: Introduce an authorized Write API that can be called by the Admin deployment. This API will allow the Admin to send configuration changes to the Site deployment securely.
Admin Authentication: The Admin deployment will be responsible for signing the requests sent to Live.ts. It will expose a public key that must be used to validate the signature of the requests, ensuring that they originate from the Admin deployment. This provides a mechanism for authentication and ensures the integrity of the configuration changes.
Key Rotation: Implement a mechanism to easily rotate the authentication key used by the Admin deployment. This will enhance security and allow for key management practices such as key revocation or key updates.
Trusted Public Keys: Enable the Site deployment to add multiple trusted public keys. This will provide flexibility in managing authentication and allow for multiple Admin deployments to interact with the Site securely.
Sites private keys: Sites should handle any necessary authorization to read/write the target Storage Provider. For instance, when dealing with supabase sites should have a key with RLS access to its own data.
Below you can see the new architecture after the suggested changes
Completion Checklist
The following tasks need to be completed to implement the proposed changes:
Design and implement the Authorized Write API endpoint.
Develop the Admin Authentication mechanism, including key generation and signature validation.
Implement key rotation functionality for the Admin deployment.
Enhance the Site deployment to support multiple trusted public keys.
Perform thorough testing and security audits to ensure the integrity and robustness of the solution.
Please share your thoughts, concerns, and suggestions to drive this proposal forward. Together, let's enhance live.ts to provide an even more reliable and flexible web framework.
The text was updated successfully, but these errors were encountered:
Title: Headless configuration API
Author: Marcos Candeia (@mcandeia)
Status: Discussion
Overview
The current architecture of live.ts is based on two main actors: the Admin and the Tenant Site, which are separate deployments. The Admin UI is responsible for writing into the configuration database, while the Tenant Site handles the read operations. However, this approach can lead to inconsistencies and limitations when dealing with configuration changes (releases). This proposal aims to address these challenges by introducing a new approach to handle configuration changes in live.ts.
Below you can see an oversimplified version of the current architecture.
Background
In the current implementation, the Admin UI is responsible for writing configuration changes into the database, and releases are published as encapsulated blobs of configurations distributed across site deployments. However, relying solely on the Admin for writing and the Site for reading can lead to inconsistencies and limitations in managing configuration changes.
Problem 1: Inconsistency in Data Store Providers
The Admin UI manages multiple sites, making it challenging to handle different data store providers for each site. Storing this information within the Site deployment offers more flexibility and autonomy for each site to define its own data store infrastructure.
Problem 2: Validation and Open Source Flexibility
Allowing the Site deployment to validate against the current JSONSchema state offers greater control and flexibility. It also enables the possibility of creating a fully open-source version where the database can be switched to the user's file system, providing alternative storage options.
Problem 3: Authorization and Cross-Deployment Access
Enabling the Site deployment to have specific authorization keys allows for more secure and granular control over data storage. For example, in the case of running on Deno, Deno KV can be inaccessible for cross read/write operations between the Admin deployment and the Site Deno KV deployment.
Detailed Design
To address the challenges mentioned above, this proposal suggests the following changes to live.ts:
Authorized Write API: Introduce an authorized Write API that can be called by the Admin deployment. This API will allow the Admin to send configuration changes to the Site deployment securely.
Admin Authentication: The Admin deployment will be responsible for signing the requests sent to Live.ts. It will expose a public key that must be used to validate the signature of the requests, ensuring that they originate from the Admin deployment. This provides a mechanism for authentication and ensures the integrity of the configuration changes.
Key Rotation: Implement a mechanism to easily rotate the authentication key used by the Admin deployment. This will enhance security and allow for key management practices such as key revocation or key updates.
Trusted Public Keys: Enable the Site deployment to add multiple trusted public keys. This will provide flexibility in managing authentication and allow for multiple Admin deployments to interact with the Site securely.
Sites private keys: Sites should handle any necessary authorization to read/write the target Storage Provider. For instance, when dealing with supabase sites should have a key with RLS access to its own data.
Below you can see the new architecture after the suggested changes
Completion Checklist
The following tasks need to be completed to implement the proposed changes:
Please share your thoughts, concerns, and suggestions to drive this proposal forward. Together, let's enhance live.ts to provide an even more reliable and flexible web framework.
The text was updated successfully, but these errors were encountered: