Difference between revisions of "NATS API Best Practices"
TmmStephen (talk | contribs) |
TmmStephen (talk | contribs) |
||
| Line 3: | Line 3: | ||
}} | }} | ||
| − | <pre style="color: red;font-weight: bold;">Please note: This information is best represented on NATS versions higher thatn 4.1.16.1''' | + | <pre style="color: red;font-weight: bold;">Please note: This information is best represented on NATS versions higher thatn 4.1.16.1'''</pre> |
| + | |||
Revision as of 15:48, 28 June 2017
Please note: This information is best represented on NATS versions higher thatn 4.1.16.1'''
The following lists out several best practices for using the NATS API. These practices are encouraged in order to prevent unwanted access to processes within NATS that would otherwise not be available unless logged in. We encourage you to use the REST API system rather than the SOAP API system as we are deprecating the SOAP API system in NATS.
Restrict Access by IP Address
In the configuration admin under the "Security" section, you are able to make use of the API you will need to provide a list of IP addresses who will have access to the NATS API. This information is set as a comma separated list of IP addresses set in the "ADMIN_API_ALLOWED_IPS" variable. We recommend that you put the IP addresses of only those who will be actively using the API itself.
API ON/OFF switch
In addition to allowing only certain IP addresses you will need to turn the API itself on. In the configuration under the "Security" section, turn on the API by checking the box for "ENABLE_SOAP_API" or "ENABLE_REST_API" depending on which system you are planning on using. This configuration is turned off by default and allows you to quickly turn off both the SOAP and REST API to all users should the need arise. We recommend having only the API system you plan to use be enabled.
API Users per System or Server
We recommend having separate API Accounts for separate uses or servers. This makes it so access to the API systems are limited should that account be compromised. Examples of this type of set up would be having one account to be used within your members area, while another account be used on an external Adtool system. If you have members areas on separate servers it would be best to have an account per server as well.
API Permissions
For each account able to access the API system, we provide the ability to restrict the resources or functions available to them. The permissions system allows you to only make available those systems that the account would use. We encourage you to only make available those functions or resources that are necessary to the account itself. If the account is used for Membership authentication, only allow them access to the member search function.
SOAP API Permissions
By default, an account has access to all SOAP API functions available and you are able to disable all those options that are not necessary for that account. Use the check boxes next to each of the functions to select which you wish to make either Enabled or Disabled. Once selected, use the "Disable APIs -->" and "<-- Enable APIs" to move the function from one column to another. You can also use the "Auto Check:" links to quickly check "All", "None", or "Invert" your selection before switching functions to be Enabled/Disabled.
REST API Permissions
By Default, an account does not have any access to the available REST API resources available. Use the check boxes in the "Enabled" column to set which of these of the collection, method, and resource combinations is enabled for this Account. Save the configuration by clicking "Save REST API Permissions" at the bottom of the page. Collections, Methods, or Resources set with "Any" allow the Account access to any of the specific option in the combination. For example, Collection/Method/Resource with each option set to "Any" allows the Account access to all REST API functions where as the Collection of "Adtool" and Method/Resource set to "Any" will give the Account access to all functions available only in the "Adtool" collection.
Examples of API Settings
Membership Authentication API Account
This example shows the settings that would be set for an account that would be used as a form of membership authentication through a restricted members area. The image on the Left shows the SOAP API permissions for this account only have access to the functions: get_member_details, record_member_login, and set_member_details. The image on the right shows the account set to the equivilant resources. In this example, this account would be used to authenticate, to record the login to NATS, and to allow the update of member information.
Members area across multiple Servers
If you have members areas across multiple servers we recommend utilizeing an account per server as shown in this example.
