Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] Headless configuration API #288

Open
5 tasks
mcandeia opened this issue Jun 12, 2023 · 0 comments
Open
5 tasks

[Proposal] Headless configuration API #288

mcandeia opened this issue Jun 12, 2023 · 0 comments
Labels

Comments

@mcandeia
Copy link
Contributor

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.

image

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
image

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant