The i-net CoWork server provides API access to a given set of functions. Users must have the Web API access permission to use it. Furthermore, users may be required to have permissions for specific functions as well.

The following list of API end-points is available to the current user:

The extension list is not available in Help Center Mode.

Requests can be customized to some extent: users can set the HTTP method (POST, GET, HEAD ...), update dynamic parts of the URL, e.g. IDs that address specific webAPI contexts, request headers as well as the request JSON.

The URL path is usually not editable, except for the parts that accept IDs for example. When editing ID parts and navigating further in the side navigation, these ID parts will be stored remembered for the current browsing page so that users can seamlessly jump forward and backward. Re-sending a request can be done using the Send button.

Using the options menu besides the Send button allows enabling the Preview Mode, show the JSON data input area and the area for additional Request Headers.

Additional Custom Request Header can be sent along a request if required by a WebAPI endpoint. These can be, e.g. Bearer Token.

The JSON Post Data area allows sending along a JSON request required for a specific WebAPI endpoint. Hints about the required JSON are usually given in the help page below the response area.

Note: Some HTTP methods do not support posting JSON data. The area is deactivated then.

The preview mode is an option at the response panel of the Web API Remote GUI. If enabled, it will send additional information to the server which can decide to not actually execute a given command.

If a command is executed with actual data in preview mode heavily depends on the command. Usually, the preview mode makes sense for potentially destructive commands like delete.

The response area of the Web API remote GUI consists of the request URL, the response status code and -message. An option panel allows toggling the preview mode (on by default).

If the response status message wasn't set, it will display a generic message (three points: ...). This usually happens when an API points sends back binary data.

Note: Binary data responses can result in a Download button being display instead of a JSON (or other available formats) response. The request is performed again when clicking the Download button. That means that the command will be executed on the server twice.

Request to the Web API require proper authentication. Many of the pre-installed authentication provider support the BASIC authentication scheme.

# REQUEST
POST /api HTTP/1.1
Authorization: Bearer VGhpcyBpcyBqdXN0IGEgZGVtbyBhY2Nlc3MgdG9rZW4u
Content-Type: application/json

Each session consumes memory and slows down the server.

When using the BASIC authentication scheme, a session is created, and it is important to reuse this session for subsequent requests. Otherwise, unnecessary sessions may accumulate, which can slow down the server. To prevent this from happening, an additional defender plugin is available, which limits the number of sessions created within a certain timeframe and blocks the user and IP from logging in if exceeded.

Solution: To avoid creating unnecessary sessions, either reuse the session by sending the Session Cookie with each request, or use the Token Authentication plugin. With the Token Authentication plugin, each request logs in the user without creating a session, making the requests stateless.

The installed OAuth2 provider additionally support a token/bearer authentication scheme. The token has to be sent using the header Authorization: Bearer <access_token>. The token itself has to be acquired from the originating provider, e.g. GitHub. The token will then be checked against the originating OAuth provider - more information: OpenID spezification.

# REQUEST
POST /api HTTP/1.1
Authorization: Bearer VGhpcyBpcyBqdXN0IGEgZGVtbyBhY2Nlc3MgdG9rZW4u
Content-Type: application/json

A user authenticated by an access token will be granted the same permissions the user would have using login credentials.

Windows Authentication using NTLM is a challenge-response based authentication protocol that requires multiple requests to complete. Here are the steps involved in the process:

1. The client initiates the authentication process by sending a request to the API endpoint. This can be done by either:
   • adding the query parameter ?login=windows to the URL
   • or by sending the request with an Authorization: NTLM header
2. The server responds with a challenge in the form of a NTLM token, which the client must use to compute a response.
3. The client sends another request to the API endpoint, including the computed response in the request headers.
4. The server verifies the response and, if correct, grants access to the API.

Note: It's important to keep track of the session cookie by sending it along with each subsequent request to maintain state.

Note: The client-side implementation of NTLM authentication must be handled by either custom code or by using libraries that can manage the authentication process for you.

Note: For NTLM / windows authentication to be used, the plugin has to be enabled and used as System Authentication provider.

# First Request
 
# REQUEST
POST /api HTTP/1.1
Authorization: NTLM TlRMTVNTUAABAAAAB7IIogAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==
Content-Type: application/json
 
# RESPONSE with actual challenge
HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM TlRMTVNTUAACAAAAAAAAACgAAAABggAAU3J2Tm9uY2UAAAAAAAAAAA==
Content-Length: 0
Date: Mon, 14 Feb 2023 06:48:54 GMT

# Secod Request
 
# REQUEST with NTLN response computed by the client based on the challenge
POST /api HTTP/1.1
Authorization: NTLM TlRMTVNTUAADAAAAGAAYAEgAQABQAQAAYAAAABAAEADgAAAA1TSU1BAAAAD05NTUxNTkxM0UyMg==
Content-Type: application/json
 
# RESPONSE
HTTP/1.1 200 OK
Content-Length: ...
Date: Mon, 14 Feb 2023 06:48:55 GMT