RFC - Multi tenant apps #72
Replies: 3 comments 2 replies
-
Single Tenant Appgraph TD
S1[Saleor Instance 1] -->|webhooks| A1[App 1]
A1 -->|GQL API| S1
S1 -->|webhooks| A2[App 2]
A2 -->|GQL API| S1
S2[Saleor Instance 2] -->|webhooks| A3[App 3]
A3 -->|GQL API| S2
One deployment of the application can communicate with only one Saleor Instance. Auth token and domain are kept in the environment variables (as implemented in the saleor-app-template). Pros:
Cons:
InstallationsequenceDiagram
participant SI1 as Saleor Instance 1
participant A as App
participant SI2 as Saleor Instance 2
alt Registration process
SI1->>+A: Calling /api/register endpoint
A->>A: Saving the instance domain and auth token in the env vars
A->>A: Restart the application
A->>-SI1: Registration complete
end
Notes:
Handling Saleor webhooksDuring installation process, the app can subscribe to application events (ie product updated, order created, etc.). When processing them, additional calls sequenceDiagram
participant SI1 as Saleor Instance 1
participant A as App
participant SI2 as Saleor Instance 2
alt Webhook request handling
SI1->>+A: Webhook product_updated calls /api/webhooks/product
A->>A: Confirm webhook domain is the same as saved
A->>A: Perform webhook payload validation
A->>A: Get saved auth token
A->>+SI1: Call GQL API for app's private metadata
SI1->>-A: Return list of private metadata
A->>A: Process the webhook
A->>-SI1: Status 200: webhook processed
end
alt Webhook from unknown instance
SI2->>+A: Webhook product_updated calls /api/webhooks/product
A->>A: Check if request domain is the same as saved
A->>SI2: Status 403: unknown instance, access denied
end
Handling external webhooks/actionssequenceDiagram
participant SI1 as Saleor Instance 1
participant A as App
participant E as External Warehouse Management System
alt External webhook
E->>+A: Webhook
A->>A: Determine if external webhook is trusted
A->>A: Get Saleor domain and auth token from env variables
A->>+SI1: Mutation via GQL API
SI1->>-A: Response
A->>-E: Response
end
Dashboard extensionsapp-sdk and app-bridge are taking care of attaching tokens to requests originating from the dashboard extensions. The app can validate auth tokens and source domains. |
Beta Was this translation helpful? Give feedback.
-
Multi Tenant Appgraph TD
S1[Saleor Instance 1] -->|webhooks| A1[App 1]
A1 -->|GQL API| S1
S2[Saleor Instance 2] -->|webhooks| A1
A1 -->|GQL API| S2
One app deployment can communicate with one or more Saleor instances. RegistrationsequenceDiagram
participant SI1 as Saleor Instance 1
participant A as App
participant SI2 as Saleor Instance 2
participant SI3 as Saleor Instance 3
alt Registration process
SI1->>+A: Calling /api/register endpoint
A->>A: Saving the instance domain and auth token in the database
A->>-SI1: Registration complete
end
alt Registration process - multiple instances
SI2->>+A: Calling /api/register endpoint
A->>A: Saving the instance domain and auth token in the database
A->>-SI2: Registration complete
end
Notes:
Handling Saleor webhookssequenceDiagram
participant SI1 as Saleor Instance 1
participant A as App
participant SI2 as Saleor Instance 2
participant SI3 as Saleor Instance 3
alt Webhook request handling from multiple instances
SI1->>+A: Webhook product_updated calls /api/webhooks/product
A->>A: Confirm the webhook domain is the same as saved ealier
A->>A: Get saved auth token
A->>+SI1: Call GQL API for app's private metadata
SI1->>-A: Return list of private metadata
A->>A: Process the webhook
A->>-SI1: Status 200: webhook processed
SI2->>+A: Webhook product_updated calls /api/webhooks/product
A->>A: Confirm webhook domain is the same as saved
A->>A: Get saved auth token
A->>+SI2: Call GQL API for app's private metadata
SI2->>-A: Return list of private metadata
A->>A: Process the webhook
A->>-SI2: Status 200: webhook processed
SI3->>+A: Webhook product_updated calls /api/webhooks/product
A->>A: No entries in the database from instance 3
A->>-SI3: Status 403: webhook rejected - unknown instance
end
Handling External webhooks/actionssequenceDiagram
participant SI1 as Saleor Instance 1
participant E1 as External WMS 1
participant A as App
participant E2 as External WMS 2
participant SI2 as Saleor Instance 2
alt Webhook from external source 1
E1->>+A: Webhook
A->>A: Based on webhook app determine which saleor instance should be notified
A->>A: Get auth token related to the instance
A->>+SI1: Call GQL API
SI1->>-A: Response
A->>-E1: Response
end
alt Webhook from external source 2
E2->>+A: Webhook
A->>A: Based on webhook app determine which saleor instance should be notified
A->>A: Get auth token related to the instance
A->>+SI2: Call GQL API
SI2->>-A: Response
A->>-E2: Response
end
Dashboard extensionsapp-sdk and app-bridge are taking care of attaching tokens to requests originating from the dashboard extensions. The app can validate auth tokens and source domains. |
Beta Was this translation helpful? Give feedback.
-
App data storageIn this post, I would like to describe a few methods for keeping app data. From the application point of view, there are a few types of data:
Environment variablesATM Saleor-app-template uses env vars to keep domain/token assigned during the app installation. Pros:
Cons:
App metadataEvery installed app can modify its private metadata in the Saleor API. Metadata are pair of keys and values kept in the plaintext. Saleor-app-template uses it by default to keep application configuration. Pros:
Cons:
External persistent storageAnother approach is to use additional services to keep the app's data:
Pros:
Cons:
Public key infrastructure
Reverse the approach - token is provided by the app and saved in the Saleor instance. Instead of storing multiple Saleor-issued tokens in the app backend, we want to revert direction here. We want to:
Saleor will verify signatures using the public key available in its database and authenticate an application (lookup will be done using App.identifier field) comparing signatures on that JWT token. sequenceDiagram
participant SI1 as Saleor Instance 1
participant A as App
alt Registration process
SI1->>+A: Calling /api/register endpoint
A->>-SI1: Registration with application `targetTokenUrl`
SI1->>SI1: `targetTokenUrl` saved in the AppInstallation
end
alt Calling the Saleor GQL API
A->>+SI1: Call GQL API
SI1->>SI1: Find AppInstallation object based on the request header
SI1->>SI1: Validate request token with the data from `targetTokenUrl`
SI1->>-A: Response
end
Pros:
Cons:
|
Beta Was this translation helpful? Give feedback.
-
TLDR:
Scenarios
App during its lifetime has to handle a few scenarios.
Registration
Before the application can access the GQL API, the registration process is required. During this process, auth data are exchanged:
Handling Saleor webhooks
There are two types of webhooks
Webhook payloads contain signatures, which are used to determine if the request originated from a valid source and has not been changed by malicious actors. Read more
Handling external webhooks/actions
Some applications will respond not only to Saleor events but also to events from external services. Let's use Warehouse Management System (WMS) integration as an example:
"External action" doesn't need to be a webhook; it could be scheduled action run by the app server.
Dashboard extensions
During the installation, the app can specify additional actions extending the Saleor Dashboard. Those extensions can be used via modal windows and buttons displayed directly in the Dashboard interface.
Read more
Beta Was this translation helpful? Give feedback.
All reactions