HTTP(S) (Channel Settings)
Introduction: HTTP and Lobster_data.
See also: General Channel Settings, HTTP (Input Agent), HTTP (Input Agent Cron) and Response Route HTTP(S).
(1) The subtype HTTPS (HTTP over SSL) requires additional certificates. Note: Additionally, a client certificate may be required for the outgoing HTTP(S) connection. The local certificate is also used for this purpose. See also section Authentication by Client Certificate.
(2) The realm is a freely selectable name that, together with the URL, describes a set of HTTP resources that require authentication (with the same access data). See 'Basic Authentication' in section Preemptive Authentication.
(3) See section Your Access (you to partner) .
(4) See section DATEV OAuth2 Hybrid Flow for a special OAuth2 variant of DATEV.
(5) See section Preemptive Authentication.
(6) This channel type allows OAuth authentication. The goal here is to manually pick up an access token (and possibly also a refresh token). See sections OAuth 1.0 (Client) and OAuth 2.0 (Client). The received access token is then stored internally in the channel, see also (9) and (7), and used in a request to the (resource) server. Note : As soon as something is entered via the buttons, OAuth is activated (also recognizable by an exclamation mark appearing then), i.e. if the channel acts as a client, it initiates the logon to the server via the OAuth process.
Note: You will find an entry with the name SYS_HTTP_OAUTH2 (resp. SYS_HTTP_OAUTH1) in the additional IDs for an access token and an entry with the name SYS_HTTP_OAUTH2_REFRESH for a refresh token. See also function change OAUTH2 access token(a,b).
(7) If a valid refresh URL is entered here and there is a refresh token, a new access token is automatically retrieved (and stored in the channel) for each HTTP access via this channel if (9) has expired (resp. already 20 seconds before that). The expiration time (9) will be reset and the refresh token will also be updated. Use the following URL: https://<server>/oauth/token?grant_type=refresh_token&refresh_token=<refreshToken>&client_id=<clientId>&client_secret=<clientSecret>
You can also use system constants in the URL. The corresponding values for the placeholders (see tooltip in GUI) are taken from (6) or as for <server> from field Partner address. The value for <server> must be like the Endpoint URL. So replace the placeholder manually with this value in the URL if necessary.
Note: You can add &useCredentialsInHeader to the URL, for the credentials ( client_id and client_secret ) to be specified in the header instead of the body. If you add &useJSON to the URL, the HTTP method POST with content type application/json is used. All entries ¶m=value in the query are then converted to {"param": "value", ...}. In this case, the values should not be URL-encoded!
Note: Not all Authorisation Servers provide a refresh token (this is optional). According to the RFC, grant type Client Credentials shouldn't even provide one in any case. If the authorisation server does not provide a refresh token, the URL above will obviously not work. If, in this case, the initially fetched, see section OAuth 2.0 (Client), access token expires, you can also use this field to automatically fetch another 'initial' access token. However, this does not work for the Grant Type Authorisation Code, as you have to enter access data manually on an external page. Use the following URLs for this purpose.
Client Credentials: https://<server>/oauth/token?grant_type=client_credentials&client_id=<clientId>&client_secret=<clientSecret>
Password Credentials: https://<server>/oauth/token?grant_type=password&client_id=<clientId>&client_secret=<clientSecret>&username=xxxxx&password=xxxxx
(8) Here the refresh (7) can be triggered manually for test purposes. See also function refresh OAUTH2 access token(a,b,c,d,e,f,g,h,i). Note: See also https://www.rfc-editor.org/rfc/rfc6749#section-1.5 and https://www.oauth.com/oauth2-servers/making-authenticated-requests/refreshing-an-access-token/ .
(9) If an OAuth2 access token was retrieved via (6) or (8), then the expiry time is automatically entered here.
(10) See section Partner Access (partner to you).
(11) See section Partner Contacts.
(12) See section Additional IDs (in channel).
(13) If Lobster_data acts as HTTP server, authentication of the client via OAuth2 is possible. Notes: Can be turned off in configuration file ./etc/startup.xml with entry <Set name="enableOAuth">false</Set>. The access token is valid for 30 days. Can be changed with system property hub.datawizard.oauth.expiresIn=number_of_seconds. For the client-side process see section OAuth 2.0 (Client).
Authorization endpoint: <URL of Integration Server>/dw/register/oauth/authorize
Grant type |
Description |
client_credentials |
Here the client only needs client ID (14) and client secret (15). Instead of the client secret, the partner password can also be used for this grant type. The client ID is the channel ID and the client secret is based on the partner password (so it can change). |
authorization_code |
The web page via which the credentials must be entered on the client side is located under ./webapps/root/oauth2/OAuth2.html. The credentials are partner ID and partner password. |
Token endpoint: <URL of Integration Server>/dw/register/oauth/token
OAuth2 (Client and Server)
Lobster_data as OAuth2 client: See items (4), (6), (7), (8) and (9).
Lobster_data as OAuth2 server: See item (13).