SMS Settings

All security measures of ARKSSPR are based on SMS sending. Although SMS sending is not as secure as Authenticator or biometric, the use of 2FA via SMS in terms of "owned" devices and information has become widespread. ARKSSPR does not require the use of SMS, but requires users to log in via SMS once for more secure secondary email use and Authenticator application registration.

SMS settings consist of 2 parts.

  1. SMS sending settings

  2. Authorization settings for SMS sending (This setting is disabled by default)

SMS Settings

Before making SMS settings, make sure that some information and settings have been made.

  • Access to the server's SMS API address,

  • The organization providing the SMS API service allows access to your external IP Address,

  • Documentation related to SMS API service,

  • Credentials required to access the SMS API service,

  • If authorization is required, information about it.

Method Type

The method specified in the SMS API service provider's documentation should be used. The GET method shows the method in which all information goes within the URL, while the POST method shows the method in which the request goes as a package outside the URL.

GET Usage

All information is included in the URL.

https://smsapi.provider.xyz/sensms?username=abc&password=yzt&phone=<@Phone,{,###,#######}&message=<@Message>

POST Usage

There is no information in the URL. Only the address is available. The information to be sent to this address is written in the Request Body section.

https://smsapi.provider.xyz

API URL

The URL and the information provided by the SMS Service provider in its documentation are written in this field.

It is a mandatory field.

HTTP Accept

The Accept-Post HTTP Response Header signifies that the post is acceptable on the requested resource and approved document format. The Accept-Post HTTP Response header will mention one or more supported document/media types when sent as a Response to the unsupported file.

It is not a mandatory field.

Accept Header Syntax

<MIME_type>/<MIME_subtype>
Samples:
* application/x-www-form-urlencoded
* application/json
* text/xml
* text/html

<MIME_type> specifies the type of media/file (such as video or text)

<MIME_subtype> identifies the specific type of data of the MIME type represents

Content Type

Content-Type is used to specify the content type of the object. The browser determines the format and encoding type that are used to read the object based on the content type of the object. If this header is not specified, the value is generated based on the extension of the object name. If the object name does not contain an extension, the default value application/octet-stream is used as the content type of the object.

It is not a mandatory field.

Content Type Header Syntax

<MIME_type>/<MIME_subtype>
Samples:
* application/x-www-form-urlencoded
* application/json
* text/xml
* text/html

<MIME_type> specifies the type of media/file (such as video or text).

<MIME_subtype> identifies the specific type of data of the MIME type represents.

An HTTP header is a field of an HTTP request or response that passes additional context and metadata about the request or response. For example, a request message can use headers to indicate it's preferred media formats, while a response can use header to indicate the media format of the returned body.

When considered within the scope of SMS settings, the header field is used for basic authentication. In Basic Authentication, Authorize is not used. Authorization (Basic) information is added to the Header section.

It is not a mandatory field.

Request Body

In HTTP, the request body is part of the request message carrying data from the client to the server. It's crucial for methods like POST, PUT, and PATCH, used to create, update, or modify resources. For example, in a POST request to create a user account, user details are in the request body. Methods like GET or DELETE usually don't use a request body, focusing on URLs and headers for resource retrieval or deletion.

In some scenarios, this field can be used for authorization.

It is not a mandatory field.

Below is an example of using Request Body in ARKSSPR. This field must be filled in accordance with the request of the service provider.

<@Phone><@Message>

Variables

VariablePurposeFormat

Phone

"To" is used for the phone number.

<@Phone>

Phone

Formatted

<@Phone,{,###,#######} Each comma-separated field represents a field in the phone number. The 1st part shows the country code, the 2nd part shows the area code, and the 3rd part shows the phone number. The number of each pound sign determines the number of numbers that can enter this field. Country code is not entered. The country code is normalized within the phone number, otherwise the default country code ARKSSPR is used.

Message

Message to send

<@Message>

Authorization

The Authorization setting is used in non-basic authorization scenarios that require tokens.

Method Type

The method specified in the SMS API service provider's documentation should be used. The GET method shows the method in which all information goes within the URL, while the POST method shows the method in which the request goes as a package outside the URL.

GET Usage

All information is included in the URL.

https://authorization.provider.xyz/authorize?username=abc&password=yzt

POST Usage

There is no information in the URL. Only the address is available. The information to be sent to this address is written in the Request Body section.

https://authorizationapi.provider.xyz

API URL

The URL and the information provided by the authentication provider.

It is a mandatory field.

HTTP Accept

The Accept-Post HTTP Response Header signifies that the post is acceptable on the requested resource and approved document format. The Accept-Post HTTP Response header will mention one or more supported document/media types when sent as a Response to the unsupported file.

It is not a mandatory field.

Accept Header Syntax

<MIME_type>/<MIME_subtype>
Samples:
* application/x-www-form-urlencoded
* application/json
* text/xml
* text/html

<MIME_type> specifies the type of media/file (such as video or text)

<MIME_subtype> identifies the specific type of data of the MIME type represents

Content Type

Content-Type is used to specify the content type of the object. The browser determines the format and encoding type that are used to read the object based on the content type of the object. If this header is not specified, the value is generated based on the extension of the object name. If the object name does not contain an extension, the default value application/octet-stream is used as the content type of the object.

It is not a mandatory field.

Content Type Header Syntax

<MIME_type>/<MIME_subtype>
Samples:
* application/x-www-form-urlencoded
* application/json
* text/xml
* text/html

<MIME_type> specifies the type of media/file (such as video or text).

<MIME_subtype> identifies the specific type of data of the MIME type represents.

Header

An HTTP header is a field of an HTTP request or response that passes additional context and metadata about the request or response. For example, a request message can use headers to indicate it's preferred media formats, while a response can use header to indicate the media format of the returned body.

If there is no special need during authentication, the Header section is not used and is left blank.

It is not a mandatory field.

Request Body

In HTTP, the request body is part of the request message carrying data from the client to the server. It's crucial for methods like POST, PUT, and PATCH, used to create, update, or modify resources. For example, in a POST request to create a user account, user details are in the request body. Methods like GET or DELETE usually don't use a request body, focusing on URLs and headers for resource retrieval or deletion.

Request Body means the data to be sent to the API. To obtain Authorization Token, information such as username and password are written in this field. Entry must be made in the format requested by the API.

After the authorization information is entered, the system makes a request in the background. The resulting token is automatically added to the Header section during SMS sending. The administrator does not need to receive the generated token or enter it anywhere.

It is not a mandatory field.

Last updated