Identifying the issue
An issue that is frequently encountered by users who are getting started with Autify for the first time is figuring out how to test an application that is not publicly accessible via the internet.
When Autify tests your app, it does so by simulating user behavior on a cloud based browser. When that browser makes requests, they are handled by your security layer in the same way any other public origin requests are handled. So, if you have security measures in place to stop users from outside your private network accessing your application, those measures will also stop Autify from connecting. This might be the case for QA or staging servers, which are designed to be accessible only to in-house teams.
Alternatively, there might be many instances where your application is simply not reachable by external services, such as when you are developing on a local machine, or if you are running the application in a temporary container. In this case, in the same way that a third party cannot access your computer’s local server, Autify won’t be able to make the requests it needs to.
In these cases, not only will your tests fail, it can sometimes be difficult to diagnose the root cause: it may appear as though Autify has simply failed mid-test with no good indication of why. Sometimes it may appear as though Autify “stopped working” and finally timed out.
Why does it sometimes work during recording?
More confusingly, oftentimes during the recording phase, these scenarios will seem to come together with no issues at all, but break during execution.
Usually this is because at the time the recording is being made, it is done so from a workstation that is either inside the security layer, or granted some exception (e.g., via a VPN). When recording scenarios, most of the heavy lifting is performed by the Chrome plugin, which is installed on the local machine. So long as that local machine has access to the application under test, the plugin will work as expected, and so long as the local workstation has no restrictions on outgoing connections (outside of the security layer), the plugin will be able to send all the interaction data to the Autify server. In these cases, the recording of the scenario can be completed without raising any alarms, and will save successfully.
However, when running the test, Autify will play back user operations from outside the security layer, and the connection will fail.
How to test private applications
Thankfully, even if the application you wish to test is behind a security layer, it is still testable, though there may not be as straightforward as testing a publically accessible application. Autify provides two approaches for testing applications which are behind a security layer, though both of them will require some additional work and configuration.
1. Accessing Your Application Via Static IP
The first approach is to assign a static IP address to Autify, and then provide a security exception in your security layer to allow traffic from that address into the network.
An IP address is the string of numbers which describes the location of a server on the internet. For IP4 (which is the prevalent means of addressing servers currently) they are a combination of four numbers. For example,
198.51.100.0. Whenever a http request is made, the IP address of the server which made the request is visible to the server who receives the request.
Usually, the exact IP address that Autify uses to connect to your application will vary between requests. This happens because Autify connects from many different servers, and the IP addresses for those servers can sometimes change without notice. However, it is also possible to restrict requests being made from Autify to a small number of specific IP addresses. This means that no matter how many times Autify sends a request to your application, the IP address will always be the same.
You can therefore be fairly confident that any requests made from that address originated from Autify. As such, it becomes possible to configure an exception in your security layer to allow requests if they are made from that particular address, and block all others. This will let Autify connect to your application, without allowing access to malicious actors.
The advantages of using this approach is that it is relatively simple to implement. Although it is necessary to create an exception in the security layer, this is usually a straightforward procedure. Additionally, this requires no change in the underlying application, and access can be granted entirely at the network layer. For older or legacy applications, this can be particularly helpful, as it allows testing to occur without making changes to what may be volatile server environments. Similarly, no significant changes need to be made to existing Autify scenarios or test plans: if they work on a publicly accessible version of the application, then they will work on the private network.
Conversely, the main disadvantage of this approach is that it requires your application to be at least reachable via the internet. That is, even if traffic is rejected at the security layer, it should still be resolvable to a server on your network. So, for example a staging server running on Google Cloud or AWS would be a good candidate, but a local development environment would be much harder to test.
Moreover, depending on the complexity of your server environment, a static IP address may not be sufficient to grant full access to the application you wish to test. For example, networks that are secured behind proxies may have trouble if accessed from Autify, even if a consistent IP address is used.
As a final note, keep in mind that we say you can be “fairly confident”, not “absolutely confident”. Although assigning a static IP address to Autify will ensure that requests from the Autify server will always use the same address, this does not guarantee that all requests that arrive claiming to be from that address were really sent by Autify. Although IP addresses are in theory unique, it is also possible to assign a “fake” IP address to a request via a process called IP spoofing. As such, you should be careful not to disclose the static IP address. And, as a matter of general testing security, you should not store sensitive data on a testing server.
2. Accessing your application using Autify Connect
The second approach is to use a mechanism provided by Autify called Autify Connect. This system allows you to use a small program called the Autify Connect Client (installed on the server that needs to be accessible by Autify) to open a direct connection between your test server and the Autify server at the time the test is run. Rather than sending http requests directly over the internet, Autify will send the via that connection directly to your server, which will then be able to forward them on as required.
As with the static IP approach, an exception must be made in your security layer, but in this case the exception is for outgoing traffic only. Once a connection is established between your server and Autify, http requests can be made as though they originated directly from the server running the Autify Connect software, bypassing the security layer entirely. As no incoming exceptions are made, the security layer continues to operate as usual for any other requests.
Additionally, since there is no restriction to which server runs the Autify Connect program, it can be used to establish a connection between devices that would normally not be accessible, even using a static IP address, such as local development machines, or applications running on otherwise inaccessible Docker containers.
While this approach does significantly extend your reach for running automated tests, it is important to note that it comes with a much higher configuration cost than allocating a fixed IP. Asides ensuring that the Autify Connect program is installed and configured to run on the server that will establish a connection to Autify, it is also required that a mechanism exists for running the program and confirming a successful connection at the time a test is run, and for dealing with any disconections that occur while tests are running. It is also necessary to manually create the access tokens on the Autify web platform, and make them available to the Autify Connect program on your servers. This brings with it the same considerations that should be used for any secret token, such as ensuring that the value is periodically rotated, and making sure that it is not accessible via a publicly viewable channel.
Finally, while it is usually not an issue, it should be noted that as all traffic for your web application will be running through a tunnel, this may impose a small performance penalty on your tests.
Which method should you use?
The approach you take will depend on the exact nature of your network setup. As a general rule, we suggest that unless you have very specific server requirements, using a static IP is the easiest way to get started with private testing. More specifically, we recommend a static IP for applications that have a relatively simple security layer, and are already accessible via the internet. Alternatively, this is a good choice if you cannot easily configure the servers running your application, but are able to enact changes at the network layer.
Alternatively, as using Autify Connect carries many complexities that may require more engineering resources to resolve, we suggest using this approach only if you have a more complex security layer, or your application environment is not readily accessible over the internet. This is also the approach we recommend if you intend to test your application on local development machines.
Autify can easily test any public web application, but it is also subject to the restrictions that stop bad actors from accessing your private network. As such, testing an application which is behind a security layer will necessarily require some degree of additional configuration. As there are many different network setups, and many security implementations can be quite unique, it is hard to suggest one specific approach that will work in all circumstances. However, Autify provides a range of solutions that can make it easier to run tests on your privately accessible applications.
This article has presented the two approaches to private network testing that are suggested and endorsed by Autify, and hopefully has given you some background information that will help you architect your testing solution. However, if you would like some more specific advice, or you would like to discuss how you can run Autify tests over your particular server configuration, then please do not hesitate to reach our to our support team for help.