SDKリファレンス - authorization
このセクションでは、authorizationハッシュで使用可能なすべてのキーを列挙します。 一部のキーは、特定の認証タイプにのみ適用されます。 ユーザーが"Connect"をクリックした直後に、Workatoはauthorizationハッシュ内のコードを実行します。
authorizationハッシュには、コネクターが認可パラメーターを取得して使用するためのすべての指示が含まれています。 これはシンプルな場合があります: 将来のリクエストでAPIキーを配置する場所です。 より複雑な場合もあります: アクセストークンを取得するために一連のHTTPリクエストを実行する場合です。
構造
authorization: {
type: String,
client_id: lambda do |connection|
String
end,
client_secret: lambda do |connection|
String
end,
authorization_url: lambda do |connection|
String
end,
token_url: lambda do |connection|
String
end,
acquire: lambda do |connection, auth_code, redirect_uri, verifier|
Hash or Array
end,
apply: lambda do |connection, access_token|
# see apply documentation for more information
end,
refresh_on: Array,
detect_on: Array,
refresh: lambda do |connection, refresh_token|
Hash or Array
end,
identity: lambda do |connection|
String
end,
pkce: lambda do |verifier, challenge|
Hash
end,
selected: lambda do |connection|
String
end,
options: Hash,
noopener: Boolean
}type
| 属性 | 説明 |
|---|---|
| キー | type |
| タイプ | 文字列 |
| 必須 | True |
| 説明 | このコネクターで使用される認証タイプを示します。 |
| 想定される出力 | 次のいずれか: "basic_auth" - Basic認証に使用します。 "api_key" - APIキー認証に使用します。 "oauth2" - OAuth 2.0認可コードグラントフローにのみ使用します。 その他のOAuthバリエーションには、"custom_auth"を使用します。 "custom_auth" - 自由形式の認証。 複数ステップ、JWT、または非標準の認証メソッドに使用します。 "multi" - 複数の認証メソッドを一度に定義できます |
client_id
| 属性 | 説明 |
|---|---|
| キー | client_id |
| タイプ | ラムダ関数 |
| 必須 | typeが"oauth2"の場合はTrueです。 それ以外の場合は無視されます |
| 説明 | 認可URLおよびトークンURLリクエストで使用するclient_idを定義します |
| 指定可能な引数 | connection - Connectionで定義されたユーザー指定入力を表すハッシュ |
| 想定される出力 | String、例: #{connection['client_id']} |
client_secret
| 属性 | 説明 |
|---|---|
| キー | client_secret |
| タイプ | ラムダ関数 |
| 必須 | typeが"oauth2"で、acquireが定義されていない場合はTrueです。 それ以外の場合は無視されます |
| 説明 | トークンURLリクエストで使用するclient_secretを定義します |
| 指定可能な引数 | connection - Connectionで定義されたユーザー指定入力を表すハッシュ |
| 想定される出力 | String、例: #{connection['client_secret']} |
authorization_url
| 属性 | 説明 |
|---|---|
| キー | authorization_url |
| タイプ | ラムダ関数 |
| 必須 | typeが"oauth2"の場合はTrueです。それ以外の場合は無視されます。 |
| 説明 | OAuth 2.0認可コードグラントフローでユーザーを送信する認可URLを示します。 |
| 指定可能な引数 | connection - Connectionで定義されたユーザー指定入力を表すハッシュ。 |
| 想定される出力 | String 例: "https://podio.com/oauth/authorize" または "#{connection['domain']}/oauth/authorize" |
Workatoは、認可URLに次の標準OAuth 2.0パラメーターを自動的に追加します:
- state
- CSRF攻撃から保護するためのstate。 これは設定しないでください。Workatoはstateを使用してコールバックリクエストを適切にルーティングします。
- redirect_uri
https://www.workato.com/oauth/callbackに設定されます。設定する必要はありません。
次のクエリパラメーターを手動で設定します:
- response_type
- このクエリパラメーターは
codeに設定する必要があります。 - 例:
authorization_url: lambda do |connection| "https://acme.com/api/oauth/authorization?response_type=code" end,
認可URLにscopeを含めることもできます。
token_url
| 属性 | 説明 |
|---|---|
| キー | token_url |
| タイプ | ラムダ関数 |
| 必須 | typeが"oauth2"で、acquireが定義されていない場合はTrueです。 それ以外の場合は無視されます。 |
| 説明 | access_tokenを受け取るために使用するトークンURLを示します |
| 指定可能な引数 | connection - Connectionで定義されたユーザー指定入力を表すハッシュ |
| 想定される出力 | String 例: "https://podio.com/oauth/token" または "#{connection['domain']}/oauth/token" |
Workatoは、トークンURLに次の標準OAuth 2.0パラメーターを自動的に追加します:
- grant_type
- 常に
authorization_codeに設定されます - code
- 認可URLコールバックから受信した認可コード
- redirect_uri
- `https://www.workato.com/oauth/callback`に設定され、設定する必要はありません
- client_id
- 存在する場合、
client_idラムダから推測されます。 - client_secret
- 存在する場合、
client_secretラムダから推測されます。
acquire
| 属性 | 説明 |
|---|---|
| キー | acquire |
| タイプ | ラムダ関数 |
| 必須 | typeが"custom_auth"の場合はTrueです。 typeが"oauth2"の場合は任意 それ以外の場合は無視されます |
| 説明 | typeが"custom_auth"の場合、acquireラムダ関数はrefresh_onまたはdetect_onがトリガーされた場合にのみ実行されます。 typeが"oauth2"の場合、acquireラムダ関数はauthorization_urlからコールバックを受信した後に実行されます。 |
| 指定可能な引数 | connection - Connectionで定義されたユーザー指定入力を表すハッシュ auth_code - typeが"oauth2"の場合にのみ適用されます。 認可URLコールバックから受信したauth_codeを表す文字列。 redirect_uri - 使用中のWorkato DCに基づいて適切なリダイレクトURIを提供します。例: US DCはhttps://www.workato.com/oauth/callbackになります。 verifier - PKCE認証でのみ使用され、pkceラムダで定義されたverifierにアクセスできます。 |
| 想定される出力 | 変数 - 以下の例を参照してください。 |
例 - acquire: - type: "oauth2"
typeとして"oauth2"を指定した場合、acquireブロックはハッシュの配列を出力として期待します。 配列には、次の値を順番に含める必要があります:
- トークン
- トークンは、正確なキー名を持つハッシュに含める必要があります:
access_token、refresh_token、refresh_token_expires_in。 - 所有者ID
- これはclobber検出に使用される任意の値です。使用しない場合はnilで置き換えます。
- その他の値
- APIが
id_accessやid_refreshなど、他のキーでトークンを返す場合は、ここでマッピングできます。 元の`connection`ハッシュとマージできる任意のハッシュを指定します。
acquire: lambda do |connection, auth_code|
response = post("https://login.mypurecloud.com/oauth/token").
payload(
grant_type: "authorization_code",
code: auth_code,
redirect_uri: "https://www.workato.com/oauth/callback"
)
[
{ # This hash is for your tokens
access_token: response["access_token"],
refresh_token: response["refresh_token"],
refresh_token_expires_in: response["refresh_token_expires_in"]
},
# This hash is for your Owner ID. It is optional
nil,
# This is for any other value you want to append to your connection object which you can reference later on.
{ instance_id: nil }
]
end,キーrefresh_token_expires_inは、更新トークンが期限切れになるまでの現在からの秒数を示します。 Workatoはジョブがある場合にのみコネクションを更新することを認識するため、ジョブがまれにしか発生しないレシピでは、有効期間の短い更新トークンが期限切れになる場合があります。 たとえば、更新トークンが1週間で期限切れになり、レシピが2週間に1回しか実行されない場合、レシピが実行される時点でコネクションのアクセストークンと更新トークンの両方が期限切れになります。
キーrefresh_token_expires_inを指定すると、Workatoはジョブを必要とせずにコネクションを自動的に更新し、必要な期間だけコネクションを維持します。 Workatoはすでにこの時間にバッファーを追加するため、この時間にバッファーを追加する必要はありません。 たとえば、refresh_token_expires_inが100秒の場合、85秒の時点でコネクションを更新します。
場合によっては、APIが更新トークンの有効期限を返さないことや、実際のタイムスタンプで返すことがあります。 更新トークンの有効期間がわかっている場合は、refresh_token_expires_in値を人為的に作成することもできます。
acquire: lambda do |connection, auth_code|
response = post("https://login.mypurecloud.com/oauth/token").
payload(
grant_type: "authorization_code",
code: auth_code,
redirect_uri: "https://www.workato.com/oauth/callback"
)
[
{ # This hash is for your tokens
access_token: response["access_token"],
refresh_token: response["refresh_token"],
refresh_token_expires_in: 604800 # Value in seconds. You can provide the value manually as well.
},
# This hash is for your Owner ID. It is optional
nil,
# This is for any other value you want to append to your connection object which you can reference later on.
{ instance_id: nil }
]
end,例 - acquire: - type: "custom_auth"
typeとして"custom_auth"を指定した場合、acquireラムダ関数は単一のハッシュを出力として期待します。 その後、Workatoは出力を元のconnectionハッシュにマージします。
authorization: {
acquire: lambda do |connection|
{
authtoken: get('https://accounts.zoho.com/apiauthtoken/nb/create')
}
end,
refresh_on: 401元のconnectionハッシュ:
{
"email": "[email protected]", # Given by User
"password": "pinkfloyd" # Given by User
}ユーザーが"Connect"ボタンをクリックすると、Workatoはconnectionハッシュを使用してtestラムダを呼び出します。 testラムダがエラーコード401で失敗した場合など、Workatoはacquireブロックを実行します。
acquireブロックの実行後、connectionハッシュは次のようになります:
{
"email": "[email protected]", # Given by User
"password": "pinkfloyd" # Given by User
"authtoken": "SAMPLE_TOKEN"
}その後、Workatoは新しいconnectionハッシュを使用して、testラムダの呼び出しを再試行します。 testラムダが成功すると、コネクションはSuccessfulとして表示されます。
connectionハッシュに有効なトークンが含まれている可能性があるため、Workatoはシステムがrefresh_onをトリガーした場合にのみacquireを実行します。 例:
- ユーザーが
authtoken値を持つ有効なコネクションから切断する場合 - ユーザーがConnectをクリックし、Workatoが新しい
authtokenではなくこのauthtokenを使用しようとする場合
apply
| 属性 | 説明 |
|---|---|
| キー | apply |
| タイプ | ラムダ関数 |
| 必須 | True |
| 説明 | Workatoがコネクター内の後続のHTTPリクエストに追加する認証パラメーターを定義します。 |
| 指定可能な引数 |
|
例 - apply
applyブロックのラムダ関数は、すべてのリクエストに認可パラメーターを添付する複数のコマンドを出力できます。 次の例は、一般的なメソッドを示しています:
apply: lambda do |connection|
# Adds in URL parameters passed as a hash object
# i.e. authtoken=[connection['authtoken']]
params(authtoken: connection['authtoken'])
#Adds in payload fields (PATCH, POST, PUT only) passed as hash
payload(grant_type: "authorization_code",
client_id: connection["client_id"],
client_secret: connection["client_secret"],
code: auth_code)
# Adds in headers into every request passed as a hash.
# The variable access_token can be retrieved from input prompts defined in the 'fields' schema earlier or a return from the acquire block
# i.e. Authorization : Bearer [given access token]
headers("Authorization": "Bearer #{connection["access_token"]}")
# Used in conjunction with password function
# i.e. sends the input as username and password in HTTP authentication
user(connection["username"])
password(connection["username"])
end現在のリクエストのペイロードにアクセスして変更する
applyメソッドを使用して、現在のリクエストのペイロードにアクセスして変更できます。 これは、既存のペイロードを更新したり、情報をヘッダーにコピーしたりする場合に便利です。
次の例は、最終リクエストが送信される前に、コネクションからuser_idをペイロードに追加する方法を示しています:
apply: lambda do |connection|
if connection['user_id'].present? # Check if user_id exists in the connection
params = {}
payload do |current_payload| # Access the current payload
params = current_payload.dig('params') # Extract the params hash
end
params['user'] = connection['user_id'] # Insert user_id from the connection
payload({ "params": params }) # Merge the updated params into the payload
end
endapplyラムダ関数で呼び出すことができる特別な変数は次のとおりです:
current_url- 現在のURLに対する一致を有効にし、適切な認証を適用します。
apply: lambda do |_connection, access_token| if current_url.include?('https://developer.api.autodesk.com/cost/') headers('Authorization': "Bearer #{access_token}", 'Content-Type' => 'application/json') else headers('Authorization': "Bearer #{access_token}", 'Content-Type' => 'application/vnd.api+json') end endcurrent_verb- 現在のHTTP動詞に対する一致を有効にし、適切な認証を適用します。
apply: lambda do |_connection, access_token| if current_verb.include?('GET') headers('Authorization': "Bearer #{access_token}", 'Content-Type' => 'application/json') else headers('Authorization': "Bearer #{access_token}", 'Content-Type' => 'application/vnd.api+json') end end
refresh_on
これは、システムが認証情報を再取得する必要があるタイミングを識別するシグナルの任意の配列です。 エラーレスポンス(400、401、500など)を受信すると、SDKフレームワークはシグナルのリストを確認します。 一致が見つかると、type: oauth2コネクションの場合はrefreshラムダ関数を実行し、type: custom_authコネクションの場合はacquireブロックを実行して、再認可をトリガーします。
| 属性 | 説明 |
|---|---|
| キー | refresh_on |
| タイプ | 配列 |
| 必須 | False. 定義されていない場合、すべてのエラーに対して認証情報の再取得を1回試行することがデフォルトになります。 |
| 説明 | 認証情報を更新するタイミングをWorkatoに通知します。 これは、HTTPレスポンスコードに一致する整数、またはレスポンス本文に一致するRegex式の配列を受け入れます。 |
| 想定される出力 | 整数または文字列の配列 - [ 401, /Unauthorized/ ] |
例 - refresh_on:
この例は、監視する"signals"を定義する複数のアプローチを示しています。
- 401
- レスポンスステータスコード
- "Unauthorized"
- レスポンスの本文全体またはタイトルに一致する正確な文字列
- /Unauthorized/
- レスポンスの本文またはタイトルに一致する正規表現
refresh_on: [
401,
'Unauthorized',
/Unauthorized/,
/Invalid Ticket Id/
]detect_on
一部のAPIは、401などの明示的なレスポンスステータスコードでエラーを通知しません。 代わりに、エラーを示すペイロードを含む200(疑似的な成功レスポンス)を返します。
このようなAPIでは、Workatoはエラー(期限切れの認証情報、不正なリクエストなど)を検出しません。200レスポンスコードのため、成功したリクエストとして解釈します。 ただし、シグナルに一致するとエラーが発生します。 一致が見つかった場合、次の2つのことが発生する可能性があります:
refresh_onシグナルにも一致する場合があります。 これにより、システムがエラーを発生させる代わりにacquireブロックが実行される再認可がトリガーされます。 次に、detect_onは200レスポンスコードの背後に隠れているエラーと一致し、システムが認証情報を更新する必要があることを識別します。refresh_onで定義されているシグナルに一致しない場合、システムはエラーを発生させます。
| 属性 | 説明 |
|---|---|
| キー | detect_on |
| タイプ | 配列 |
| 必須 | False |
| 説明 | リクエストへのレスポンス内のシグナルにより、エラーを発生させるタイミングをWorkatoに通知します。 これは、HTTPレスポンスコードに一致する整数、またはレスポンス本文に一致するRegex式の配列を受け入れます。 |
| 想定される出力 | 整数または文字列の配列 - [ 401, /Unauthorized/ ] |
例 - detect_on
この例は、detect_onで監視する"signals"を定義する複数のアプローチを示しています。
- "sample error message"
- レスポンスの本文全体またはタイトルに一致する正確な文字列
- /^\{"response":\{"error".+$/
- レスポンスの本文またはタイトルに一致するRegex式
detect_on: [
"sample error message",
/^\{"response":\{"error".+$/
]refresh
このラムダはtype: "oauth2"コネクションにのみ適用されます。
多くの場合、APIは規定の時間が経過するとアクセストークンを期限切れにします。 その後、システムは更新トークンを使用して新しいアクセストークンを取得します。 通常、更新トークンは期限切れになりません。
すべてのAPIがリフレッシュトークン認証情報を発行するわけではありません。 この要件については、プロバイダーに確認してください。
| 属性 | 説明 |
|---|---|
| キー | refresh |
| タイプ | ラムダ関数 |
| 必須 | Falseですが推奨され、type: oauth2コネクションにのみ有効です。 |
| 説明 | この関数は、いずれかのAPIリクエストで非2XXレスポンスを受信した場合、refresh_onシグナルがトリガーされた場合、または更新トークンの期限切れが近いことをWorkatoが認識した場合に実行されます。 これは新しいアクセストークンを取得するために使用されます。 これが定義されていない場合、Workatoは可能であれば標準のOAuth 2.0更新メカニズムを使用しようとするか、acquireラムダ関数を再実行します。 |
| 指定可能な引数 | connection - Connectionで定義されたユーザー指定入力を表すハッシュ refresh_token - トークンURLまたはacquireブロックから受信したrefresh_tokenを表します。 |
| 想定される出力 | 新しいアクセストークンを含むハッシュ。 任意で、このハッシュには新しい更新トークン(元の更新トークンを上書きします)と、Workatoがアクセストークンと更新トークンを更新するまでの遅延時間を含めることができます。 以下の例を参照してください。 |
例 - refresh
type:として"oauth2"を指定した場合、refreshブロックはハッシュを出力として期待します。 このハッシュには、access_tokenのキーと、システムが毎回新しい更新トークンを作成する場合はrefresh_tokenのキーを含める必要があります。
更新トークンが期限切れになるまでの現在からの秒数を示すキーrefresh_token_expires_inも含めることをお勧めします。 Workatoはジョブがある場合にのみコネクションを更新することを認識するため、ジョブがまれにしか発生しないレシピでは、有効期間の短い更新トークンが期限切れになる場合があります。 たとえば、更新トークンが1週間で期限切れになり、レシピが2週間に1回しか実行されない場合、レシピが実行される時点でコネクションのアクセストークンと更新トークンの両方が期限切れになります。
キーrefresh_token_expires_inを指定すると、Workatoはジョブを必要とせずにコネクションを自動的に更新し、必要な期間だけコネクションを維持します。 Workatoはすでにこの時間にバッファーを追加するため、この時間にバッファーを追加する必要はありません。 たとえば、refresh_token_expires_inが100秒の場合、85秒の時点でコネクションを更新します。
たとえば、更新トークンURLからのレスポンスが次のような場合:
{
"access_token": "new_access_token",
"refresh_token": "new_refresh_token",
"refresh_token_expires_in": 604800
}次に、API呼び出しのHTTPリクエストを次のように設定する必要があります:
refresh: lambda do |connection, refresh_token|
url = "https://#{connection['custom_domain'].presence || 'go.trackvia.com'}"
response = post("#{url}/oauth/token").payload(
client_id: connection['client_id'],
client_secret: connection['client_secret'],
grant_type: 'refresh_token',
refresh_token: refresh_token
).request_format_www_form_urlencoded
end,または、コネクションハッシュの値を上書きまたは追加するハッシュの配列を返すには、次のように実装します:
refresh: lambda do |connection, refresh_token|
url = "https://#{connection['custom_domain'].presence || 'go.trackvia.com'}"
response = post("#{url}/oauth/token").payload(
client_id: connection['client_id'],
client_secret: connection['client_secret'],
grant_type: 'refresh_token',
refresh_token: refresh_token
).request_format_www_form_urlencoded
[
{ # This hash is for your tokens
access_token: response["access_token"],
refresh_token: response["refresh_token"],
refresh_token_expires_in: response["refresh_token_expires_in"]
},
{
user_key: user_key # Will be merged into connection hash
}
]
end,場合によっては、APIが更新トークンの有効期限を返さないことや、実際のタイムスタンプで返すことがあります。 更新トークンの有効期間がわかっている場合は、refresh_token_expires_in値を人為的に作成することもできます。
refresh: lambda do |connection, refresh_token|
url = "https://#{connection['custom_domain'].presence || 'go.trackvia.com'}"
response = post("#{url}/oauth/token").payload(
client_id: connection['client_id'],
client_secret: connection['client_secret'],
grant_type: 'refresh_token',
refresh_token: refresh_token
).request_format_www_form_urlencoded
[
{ # This hash is for your tokens
access_token: response["access_token"],
refresh_token: response["refresh_token"],
refresh_token_expires_in: 604800 # Value in seconds. You can provide the value manually as well.
},
{
user_key: user_key # Will be merged into connection hash
}
]
end,identity
identityラムダは、コネクションに関する追加情報を表示します。 この出力はコネクションページに表示され、認証済みユーザーまたはコネクションに関する追加のコンテキストを提供します。

| 属性 | 説明 |
|---|---|
| キー | identity |
| タイプ | ラムダ関数 |
| 必須 | False. |
| 説明 | ラムダを使用すると、コネクションオブジェクトに関する追加情報を表示できます。 HTTPリクエストを実行してユーザーIDの詳細を取得することも、コネクションオブジェクトの既存の値を参照することもできます。 acquireラムダからコネクションオブジェクトに値を追加する方法の詳細については、acquireラムダのドキュメントを参照してください。 これらの値はidentityラムダで参照できます。 |
| 指定可能な引数 | connection - Connectionオブジェクトで定義された入力を表すハッシュ。 |
| 想定される出力 | コネクションに関する詳細を含む文字列(例: "[email protected]"、"Refresh token expires in 86400 seconds") |
例 - identity
この例では、identityラムダがHTTP GETリクエストを実行して、サードパーティAPIからユーザー情報を取得します。 ユーザーのメールアドレスを抽出し、コネクションページに表示します。 コネクションオブジェクトにメールアドレスが直接含まれていない場合に使用します。
identity: lambda do |_connection|
get("https://app.asana.com/api/1.0/users/me")["data"]["email"]
end,このラムダを使用して、コネクションオブジェクトから値を返すこともできます。 次の例では、コネクションオブジェクトからusernameを取得します:
identity: lambda do |connection|
connection["username"]
end,さらに、コネクションオブジェクトの値を使用してラムダの出力をカスタマイズし、詳細情報を提供できます。 次の例では、Company IDを取得し、コネクションページに書式設定された文字列を表示します:
identity: lambda do |connection|
"Company ID: #{connection['company_id']}"
end,pkce
このラムダはtype: "oauth2"コネクションにのみ適用され、PKCE認証を使用するOAuth2認可コードグラントが必要な場合にのみ必要です。 このラムダを使用すると、コードベリファイア、コードチャレンジ、チャレンジメソッドなど、PKCEのパラメーターを定義できます。
| 属性 | 説明 |
|---|---|
| キー | pkce |
| タイプ | ラムダ関数 |
| 必須 | False. PKCEを使用する認可コードグラントフローにのみ必要 |
| 説明 | このラムダを使用すると、PKCEフローのパラメーターを設定できます。 これはverifierとchallengeの2つの引数を受け取ります。verifierは128文字の不透明な文字列で、challengeはverifierのSHA256であるURLセーフな文字列です。 場合によっては、より長い、またはより短いverifierが必要な場合、独自のものを指定できます。 |
| 指定可能な引数 | verifier - 128文字の不透明な文字列。 challenge - verifierのSHA256 |
| 想定される出力 | verifier、challenge、challenge_methodの3つの属性を含むハッシュ。 |
PKCEを使用した認可コードグラントフローの作成について詳しく見る。
selected
このラムダはtype: "multi"コネクションにのみ適用されます。
type: "multi"を定義するときにこのラムダを使用します。元の入力フィールドのどの入力が正しい認証タイプにマッピングされるかを指定します。 宣言されたoptionsと一緒に使用します。
selectedが定義されていないがtype: "multi"が定義されている場合、Workatoは内部名がname: "auth_type"の任意の入力をデフォルトにします
| 属性 | 説明 |
|---|---|
| キー | selected |
| タイプ | ラムダ関数 |
| 必須 | False. type: "multi"コネクションでは必須です。 |
| 説明 | Workatoはfieldsで指定された入力に基づいてこの関数を実行し、optionsハッシュで定義されたキーと一致する文字列を出力する必要があります。 内部名がauth_typeのフィールドがデフォルトになります。 |
| 指定可能な引数 | connection - Connectionで定義されたユーザー指定入力を表すハッシュ |
| 想定される出力 | optionsハッシュで定義された任意のキーと一致する文字列。 |
options
このラムダはtype: "multi"コネクションにのみ適用されます。
このハッシュには、複数の認証タイプをサポートするコネクターを計画する場合に、複数の認証フローの定義が含まれます。
| 属性 | 説明 |
|---|---|
| キー | options |
| タイプ | ハッシュ |
| 必須 | False. type: "multi"コネクションでは必須です。 |
| 説明 | "multi"認証フローコネクター内のさまざまな認証タイプの定義を含むハッシュ。 |
ネストされた認証定義のスキーマ
ネストされた認証定義を含むスキーマを検討します:
options: {
[unique_option_name]: {
type: String,
fields: Array,
client_id: lambda do |connection|
String
end,
client_secret: lambda do |connection|
String
end,
authorization_url: lambda do |connection|
String
end,
token_url: lambda do |connection|
String
end,
acquire: lambda do |connection, auth_code|
Hash or Array
end,
apply: lambda do |connection, access_token|
# see apply documentation for more information
end,
refresh_on: Array,
detect_on: Array,
refresh: lambda do |connection, refresh_token|
Hash or Array
end,
},
[Another_unique_option_name]: {
...
}
}optionsハッシュ内では、認証フローに対して2つのコンポーネントを定義する必要があります:
- 認証フローに固有のkey
- まったく新しい
authorizationハッシュに似た認証フローのmechanics。
次の例を検討します:
fields: [
{
name: "auth_type",
control_type: "select",
pick_list: [["OAuth2", "stripe_oauth2"], ["API Key", "stripe_api_key"]],
default: "api_key",
extends_schema: true
}
],
authorization: {
type: "multi",
selected: lambda do |connection|
connection["auth_type"]
end,
options: {
stripe_oauth2: {
type: "oauth2",
fields: [
{ name: 'authorization_url' },
{ name: 'token_url' },
{ name: 'client_id' },
{ name: 'client_secret' },
],
authorization_url: lambda do |connection|
connection['authorization_url']
end,
token_url: lambda do
"https://api.stripe.com/accessToken"
end,
apply: lambda do |_, access_token|
headers("Authorization": "OAuth2 #{access_token}")
end,
},
stripe_api_key: {
type: "custom_auth",
fields: [
{
name: "api_key",
}
],
apply: lambda do |connection|
headers("Authorization": "Bearer" + " " + connection["api_key"])
end
}
},
},ここでは、stripe_oauth2とstripe_api_keyの2つの認証フローを定義しました。 これらのキーは、selectedラムダの出力と一致する限り、任意のものにできます。 各フローで、ハッシュ内のすべてのラムダを確認して定義できます。 stripe_oauth2オプションでは、認証フローのtypeをoauth2、authorization_url、token_url、およびapplyブロックとして定義しました。
ここでの重要な違いは、各認証フロー内で追加のfieldsキーを定義できることです。 これにより、選択された認証メソッドに基づく入力フィールドが追加されます。Workatoはこれらのフィールドを自動的に追加します。
noopener
noopener属性はOAuth 2.0コネクションにのみ適用されます。
これはrel="noopener" HTML属性を指定します。 この属性は、新しいブラウザータブまたはウィンドウで開くリンクにrel="noopener"を追加することで、セキュリティを向上させます。
| 属性 | 説明 |
|---|---|
| キー | noopener |
| タイプ | ブール値 |
| 必須 | いいえ。 デフォルトはfalseです。 ユーザーは、セキュリティを強化するためにtrueに設定できます。 |
| 説明 | trueに設定すると、OAuth 2.0認可ページはtarget="blank"属性とrel="noopener"属性を使用して起動します。 この属性はセキュリティを向上させ、リンク先のサードパーティWebサイトがwindowオブジェクトを介してブラウザータブを制御するのを防ぎます。 |
Last updated: