# Rendering with User Input
## Introduction
In the [authentication configuration](https://locoia.gitbook.io/connectors/authentication-types), 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`)
{% hint style="info" %}
If the `api_endpoint` variable 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.
{% endhint %}
### Available variables
For security reasons, not all [variables that can be specified](https://locoia.gitbook.io/connectors/authentication-types#allowed-variables) 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](https://docs.locoia.com/connectors/connectors/everreal#authentication-and-rest-api-docs) for an example.
#### **Authentication Configuration**
```json
{
"oauth2": {
"auth_form": [
{
"name": "subdomain",
"title": "Subdomain",
"type": "text",
"required": true,
"info": "Will be filled in for {{ subdomain }} in https://{{ subdomain }}.everreal.co/api/prism/",
"pattern": "/^[\\w-_]+$/",
"regexErrorMessage": "The subdomain can only contain letters, numbers, -, and _"
},
{
"name": "environment",
"title": "Environment",
"type": "select",
"required": false,
"default": "Production",
"enum": [
"Production",
"QA"
]
}
],
"config": {
"client_id": "{% if environment is defined and environment == 'QA' %}production_client_id{% else %}qa_client_id{% endif %}",
"client_secret": "{% if environment is defined and environment == 'QA' %}production_client_secret{% else %}qa_client_secret{% endif %}",
"step1_authorize_url": "{% if subdomain is defined %}https://{{ subdomain }}.everreal.co{% else %}{{ api_endpoint | url_origin }}{% endif %}/accounts/dialog/authorize"
// ... other config values
}
}
}
```
{% hint style="warning" %}
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` to construct the OAuth2-specific URLs.
{% endhint %}
**Base Domain**
```
https://{{ subdomain }}.everreal.co/api/prism/
```
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.
To avoid overcomplicating the rendering further, all existing Snowflake Connector Auths were migrated to work with the updated Connector setup, ensuring backwards compatibility was not an issue.
#### **Authentication Configuration**
Due to the high number of required details in Snowflake, this is one of the most extensive configurations. Additionally, all fields are required, as no defaults can be set.
```json
{
"oauth2": {
"auth_form": [
{
"name": "system_id",
"title": "Organization Name",
"type": "text",
"required": true,
"info": "The name of your Snowflake organization"
},
{
"name": "account_id",
"title": "Account Name",
"type": "text",
"required": true,
"info": "The unique name of your account within your organization. https://docs.snowflake.com/en/user-guide/admin-account-identifier.html#account-name"
},
{
"name": "subdomain",
"title": "Account Locator",
"type": "text",
"required": true,
"info": "Identifier assigned by Snowflake when the account was created. https://docs.snowflake.com/en/user-guide/admin-account-identifier.html#format-2-legacy-account-locator-in-a-region"
},
{
"name": "client_id",
"title": "Client ID",
"type": "text",
"required": true,
"info": "See authentication documentation for details"
},
{
"name": "client_secret",
"title": "Client Secret",
"type": "password",
"required": true,
"info": "See authentication documentation for details"
}
],
"config": {
"client_id": "{{ client_id }}",
"client_secret": "{{ client_secret }}",
"step1_authorize_url": "https://{{ system_id | lower }}-{{ account_id | lower }}.snowflakecomputing.com/oauth/authorize"
// ... other config values
}
}
}
```
{% hint style="info" %}
Not all variable names correspond to the names used in Snowflake, as only a limited number of variable names are available to keep configurations uniform.
However, this does not matter to the user, as the title (i.e., the field name seen by the user) can be set freely.
{% endhint %}
**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:
```
https://{{ system_id | lower }}-{{ account_id | lower }}.snowflakecomputing.com/api/v2/
```
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](https://locoia.gitbook.io/connectors/authentication-types/oauth2#header), except for one custom header, whose value is rendered from the Connector Auth user input:
```json
{
...
"custom_headers": {
"Snowflake-Account": "{{ subdomain }}"
}
}
```
## 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.
```json
{
"basic_auth": {
"auth_form": [
{
"name": "account_id",
"title": "Account ID",
"type": "password",
"required": true
},
{
"name": "auth_token",
"title": "Secret Key",
"type": "password",
"required": true
}
],
"config": {}
}
}
```
**URL Token Extension**
Here the `{{ endpoint }}` always needs to be specified and the auth token is always referenced to as `token`.
```
{{ endpoint }}&secretKey={{ token }}&accountID={{ account_id }}
```
**Header**
In the Header `token_in_header` needs to be set to `false`, so that it is available in the URL Token Extension fields.
```json
{
"encode": false,
"token_in_header": false,
"content_type": "application/json",
"token_format": "{{token}}"
}
```