Paragon-neo/100G: Automation - HTTP/HTTPS Connectivity
From version R10, Paragon-neo GUI supports HTTPS/SSL connectivity as well as HTTP, this extends to the RESTful API used for automation. Further information about the implementation can be found on-instrument in the Quick Help in the System→Setup→Security Configuration and also Help→Getting Started Guide.
The handling of HTTP/HTTPS in the calnexRest wrapper follows the principle of “As secure as possible without compromising backwards compatibility with existing scripts”.
The console messages generated by the wrapper will also provide information about the connection type that is established and how to troubleshoot issues.
Currently only the Python wrapper calnexRest.py contains the extended HTTP/HTTPS handling. If you require assistance using the Tcl wrapper, please contact Calnex Support.
Operational Information
See below for information about how the wrapper handles HTTP/HTTPS connectivity in various scenarios.
Instrument Configuration
The default instrument setting after upgrading to R10 is that both HTTP and HTTPS interfaces are enabled, the user must specifically disable one of them if required. The instrument will not redirect from HTTP to HTTPS or vice-versa.
There is a default SSL certificate loaded onto the instrument, this is a private certificate and cannot be verified by users. It is included for testing only and to ensure communications are not lost to the instrument during user configuration tasks.
Python Configuration
The calnexRest.py wrapper uses the Python Requests module to interface with the instrument API.
Depending on the user Python environment, SSL certificate trust anchors may already be configured and these should extend to the Requests module used by the wrapper.
The calnexRest.py wrapper passes user set parameters directly through to the verify parameter of the request calls to allow passing of the correct parameter to enable the verification method required for the user Python HTTPS/SSL environment.
Default calnexInit Operation
The default initialisation command from the user script will still work in all cases, example:
calnexInit('192.168.207.105')
In this case the wrapper will try to use HTTPS/SSL first, if this results in an error (including a certificate error) then HTTP will be tried.
calnexInit HTTPS/HTTP Options
There are two optional keyword arguments that can be provided to calnexInit regarding HTTP/HTTPS operation, http_type and ssl_verify, example:
calnexInit('192.168.207.105', http_type='https', ssl_verify='c:/certs/cacert.crt')
More detail on these keyword arguments is below.
http_type:
The specified value (or lack of specified value) is used to apply logic to which connection types are acceptable to the user and how to handle errors with a connection type.
Valid parameters are “http” and “https”.
http_type=https only HTTPS connection will be tried.
http_type=http only HTTP connection will be tried.
If this keyword is not specified then the wrapper will try to use HTTPS/SSL first, if this results in an error (including a certificate error) then HTTP will be tried.
ssl_verify
The specified value (or lack of specified value) is used to apply logic to which connection types are acceptable to the user and how to handle errors with a connection type.
The specified value is passed directly through to the verify parameter of the Python Requests module.
Valid parameters are “True”, “False” or <path to certificate store, or specific certificate>
ssl_verify=<path to certificate store, or specific certificate> specifies the path to the certificate or certificate store to be used for verification of the certificate loaded on Paragon-neo.
ssl_verify=True specifies that the validation of the certificate loaded into the Paragon-neo will be verified using the trust anchors as configured in the user Python environment.
ssl_verify=False specifies that the validation of the certificate loaded into the Paragon-neo will not be performed. This unsecure setting is recommended for testing purposes only.