Rendering with User Input
The base domain, header, url token extension, and config can be flexibly rendered with user input from Connector Auths.
Introduction
In the authentication configuration, additional fields can be configured which are then shown in the Connector Auth creation and can be used for rendering in these fields:
Base Domain
Header (inside
custom_headers
)URL Token Extension
Authentication Configuration (inside
config
)
If the api_endpoint
variables is specified (i.e. all older Connector Auths with a custom base domain), it will always be used instead of trying to render the base domain.
This ensures that changes are backwards compatible.
Available variables
For security reasons, not all variables that can be specified can be used, only these variables are available:
account_id
api_endpoint
api_version
authorization_request_url
client_id
client_secret
config
domain
encoding
environment
grant_type
integration_code
key
port
protocol
refresh_request_url
region
scope
secret
slug
subdomain
system_id
Examples
EverReal - Custom subdomain and multiple OAuth2 environments
EverReal has custom subdomains, OAuth2, and different environments which have different client ids and secrets.
Thus, the user needs to specify their subdomain and can optionally set their environment (default is production); see our EverReal Connector docs for an example.
Authentication Configuration
In order to be fully backwards compatible, for Connector Auths created before this change (these have the api_endpoint
variable specified, which consists of the entire base domain), one needs to check whether subdomain is defined
and based on that use either the subdomain
or the api_endpoint
in order to construct the OAuth2 specific URLs.
Base Domain
As mentioned above, the base domain is backwards compatible by design, as it's by default overwritten with the api_endpoint
variables if it is specified.
All other fields are not affected by the rendering.
Snowflake - Custom subdomain, headers, OAuth2 clients
Snowflake is an especially complex connector, as it requires custom OAuth2 clients and multiple account identifiers; see our Snowflake Connector docs for more details and the rendered Connector Auth form.
In order to not overcomplicate the rendering even more, all existing Snowflake Connector Auths were migrated to work with the updated Connector setup, so that backwards compatibility was not an issue.
Authentication Configuration
Due to the high number of required details by Snowflake, this is one of the most extensive configurations. Additionally all fields are required, as no defaults can be set.
Not all variable names are corresponding to the names in Snowflake as only a limited number of variable names are available in order to keep configurations uniform.
However, for the user this does not matter, as the title (that's the field name that will be seen by the user) can be set freely.
Base Domain
For Snowflake, and most other Connectors, the 'base' part of the base domain is the same as the 'base' part of the OAuth2 authorization URL:
This is also a good example of making the input for the user as easy as possible, as users can simply copy and based their organization and account name (which are by default shown in upper case letters in Snowflake) in the form and they do not need to know how exactly the URL is constructed.
Header
The header follows the standard OAuth2 header, except for one custom header, whose value is rendered from the Connector Auth user input:
SharpSpring - URL token extension
For SharpSpring, the auth token and another variable need to be sent as query parameters instead of header values.
Authentication Configuration
The configuration is a fairly regular basic auth configuration, except for the Account ID field.
URL Token Extension
Here the {{ endpoint }}
always needs to be specified and the auth token is always referenced to as token
.
Header
In the Header token_in_header
needs to be set to false
, so that it is available in the URL Token Extension fields.
Last updated