Skip to content

IS-17883: fix some custom_auth-related typos + made membercare example more generic #1272

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.

Sign up for GitHub

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

Merged
hglad merged 2 commits into from
Jan 17, 2025
Merged

IS-17883: fix some custom_auth-related typos + made membercare example more generic #1272

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0980f16
IS-17883: fix some custom_auth-related typos
hglad Jan 17, 2025
112a83a
IS-17883: made membercare custom auth example more generic
hglad Jan 17, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions hub/documentation/service-configuration/systems/configuration-systems-rest.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -540,7 +540,7 @@ the following sub-properties:
- If the token is expected to contain the amount of time until the token expires, this
should be set to the name of the property that contains that value. The evaluated value must be in seconds.
If the provided value is not in seconds, you can use Jinja expressions to do the conversion (e.g. if a token
contains a property ``expiresIn`` that provides the token expiry in hours, you can use ``{{ expiresIn * 3600 }}``.
contains a property ``expiresIn`` that provides the token expiry in hours, you can use ``{{ expiresIn * 3600 }}``).
If ``expires_at_expression`` is also set, the ``expires_at_expression`` will take priority if it evaluates to a
valid timestamp.

Expand Down Expand Up @@ -756,7 +756,7 @@ access token:
"custom_auth": {
"get_token_operation": "fetch-session-token",
"access_token_property": "token",
"expires_at_expression": "expirationDate"
"expires_at_expression": "{{ expirationDate }}"
},
"operations": {
"contact-list": {
Expand Down Expand Up @@ -828,7 +828,7 @@ The authorization header is different from the typical bearer token format:
{
"_id": "membercare",
"type": "system:rest",
"url_pattern": "https://hoyre-rest-test.membercare.no/api/%s",
"url_pattern": "https://customer-test.membercare.no/api/%s",
"verify_ssl": true,
"custom_auth": {
"access_token_property": "value",
Expand All @@ -854,7 +854,7 @@ The authorization header is different from the typical bearer token format:
"method": "GET",
"params": {
"clientApiKey": "$SECRET(api_key)",
"personToImpersonate": "1"
"personToImpersonate": "person-to-impersonate"
},
"url": "v1/token"
},
Expand Down Expand Up @@ -917,6 +917,6 @@ fine. This just demonstrates that you can also use ``custom_auth`` in a way that
},
"payload_property": "results",
"url": "crm/v3/objects/company"
},
}
}
}