Releases: SpectoLabs/hoverfly
v0.12.2
Journal
To give more visibility as to what Hoverfly is up to, we have introduced a record of all requests and responses being served by Hoverfly. This can be found via the new admin API endpoint /api/v2/journal. Along with the requests and responses, metadata for each request is also recorded. This includes latency observed by Hoverfly and the mode it was in. By default, the journal will store the last 1000 requests and responses. The size of the journal is modifiable via a new -journal-size flag.
Hoverctl log files
With the introduction of the logs API several releases ago, and then the updating of the hoverctl logs command to use the API, we have now stopped hoverctl from writing logs to disk. If there are any .log files left you in your .hoverfly/ directory, they can now be deleted as they are no longer used by hoverctl.
Caching bug
We have fixed an issue involving caching. Hoverfly will cache each request/response it serves in an attempt to speed up matching, including failures to match. This bug occurred when
trying to match using specific header values, something that the cache cannot do due to how we hash each request.
v0.12.1
Plaintext logs from Hoverfly
With this small release of Hoverfly, we have updated the logs. Previously, Hoverfly would log out to standard out using JSON formatting. This has been updated to now use the plaintext format. If you depend on JSON formatted logs in standard out, there is now a -logs flag to set the format back to json. The logs API which can be found at /api/v2/logs will still output JSON formatted logs by default.
hoverfly -logs=json
Logs API date filter
We have expanded the logs API to now allow the ability to filter logs based on a UNIX timestamp. This can now be done by providing the from query parameter with a UNIX timestamp value. All logs returned will be after this point in time, making it easier to follow logs and only request new log entries.
Content-Type bug in Hoverfly API
With the introduction of plaintext log formatting to the logs API, a bug was noticed regarding the Content-Type header on responses from the Hoverfly API. Regardless of content, this header was always set to application/json. This has now been fixed so that the header is now correctly set regardless of response body content.
v0.12.0
After several releases of bug fixes, we are finally ready to release the next big update to Hoverfly.
Strongest match
Before v0.12.0, when matching a request in simulate mode, the first match would be returned. This could often be a problem if looser request response pairs were defined at the top of a simulation.
To get around this, we have implemented a scoring system. Each match within a request will be scored and every request response pair from a simulation will now be checked. This should result in more accurate and reliable simulations.
It is still possible to use the previous matching strategy by using the --matching-strategy=first flag when setting the mode with hoverctl.
For more information on Matching strategies
Closest match
With the introduction of scoring request response pairs to determine the most accurate match, Hoverfly can now report the closest request response pair when a request is unmatched. When this happens, an informative report of what happening during matching is now printed both to the logs as well as the HTTP error response body. This should make it much easier now to debug failing requests going through Hoverfly.
Hoverfly UI
The second update to Hoverfly comes in the form of the UI. The UI part of Hoverfly has been neglected for a long time and as a result, we have rebuilt using Angular. This new dashboard is now separate from the Hoverfly codebase in its own codebase.
For more information on Hoverfly UI
hoverfly -dev
With the change to Hoverfly UI being an external project for development, the -dev flag on Hoverfly has been updated to now enable CORS headers.
For more information on Hoverfly flags
v0.11.5
Hoverfly shutdown API
We have added a new endpoint to Hoverfly which will allow users to shutdown Hoverfly. A shutdown can be triggered by sending a DELETE HTTP request to /api/v2/shutdown. This will terminate the instance immediately.
Removed PIDs from hoverctl
With the introduction of the shutdown API on Hoverfly, hoverctl has now been updated to no longer keep track of PIDs. Instead, hoverctl will now rely only on being able to communicate with Hoverfly via the API. This should have no functional impact on how hoverctl is used.
jsonMatch ordering bug
A bug was noticed with the jsonMatch request field matcher. The bug was that the order of elements within the JSON provided was respected when matching, making this matcher more difficult to use. This should now be resolved.
Header key case bug
Another bug was spotted regarding headers served by Hoverfly. They noted that Hoverfly did not always respect the upper and lower case characters of the header keys from the simulation. This has been fixed and Hoverfly should now always send headers that match the headers from the simulation loaded.
TLS verification bug
Someone else pointed out that when setting TLS verification to false, they found Hoverfly was still applying TLS verification to proxied requests. It was promptly discovered that the TLS verification feature was working in reverse, meaning that TLS verification was disabled by default and specifying to disable it actually enabled it. This has been resolved.
WARNING if you are using Hoverfly with services in which you would like to TLS verification disabled, you will now need to set that with either hoverfly -tls-verification=false or hoverctl start --disable-tls.
v0.11.4
Logs in hoverctl
We have updated and improved the hoverctl logs command. Using hoverctl logs will now print out plain text logs. To get the logs in a JSON format like before, you can now use the new --json flag. We have renamed --follow-logs to --follow. We have also updated the way we retrieve logs. Before, we were writing the logs to disk and this was created while starting a Hoverfly process. Now, we are using the logs API from Hoverfly. This means hoverctl logs will now work with both local and remote instances of Hoverfly.
Windows bugs in hoverctl
Two bugs were found in previous versions of hoverctl that only occurred on Windows. The first bug occurred when prompted to enter a password, hoverctl would error and terminate. The other bug found was that hoverctl would not update the config file. Both of these bugs have now been fixed.
Default target in hoverctl
The hoverctl targets command has been updated to include a default target indicator in the table of targets. We have also changed the way the default target works. Now, when it points to a target that does not exist, the default target will be changed to the local target.
v0.11.3
Previous version binary size increase
As a result of updating the Hoverfly UI for v0.11.2, the Hoverfly binary increased in size. This has been fixed and the Hoverfly is now back to its original file size.
hoverctl config subcommands
To make hoverctl easier to use, we have extended the config command with four new subcommands. It is now possible to retrieve either the host, admin port, proxy port or the auth token.
hoverctl config host
hoverctl config admin-port
hoverctl config proxy-port
hoverctl config auth-token
These commands can be used to get information about specific targets. For example:
hoverctl -t target-name config host
More information on hoverctl commands
Remote Hoverfly instances and X-HOVERFLY-AUTHORIZATION
When connecting to Hoverfly, regardless if you are proxying HTTP or HTTPS requests, you still need to make an HTTP request to Hoverfly. This can be a security problem when running Hoverfly in non-local environments with authentication enabled. You may be exposing your authorization credentials or your authorization token.
To solve this problem, when starting a Hoverfly instance on a remote host, we recommend using the new -proxy-auth Hoverfly flag with the value header-auth.
This flag will disable the default security mechanisms for the proxy. Instead, Hoverfly will expect a custom security header X-HOVERFLY-AUTHORIZATION. The reason for this that depending on your HTTP client, the default Proxy-Authorization header may be included in the insecure initial request. Using a custom header will make sure the authorization token is not included in that first request.
hoverfly -auth -username bench -password password123 -proxy-auth=header-auth
Setting -proxy-auth=header-auth will enable https-only by default
v0.11.2
Proxy-Authorization header
When authentication is enabled, you can now use a Proxy-Authorization header on the requests you are sending to the proxy. This header accepts both Basic authentication with base64 encoded value and also accepts Bearer authentication with a JWT token value. In combination with this work, we've also added the ability for disabling Basic authentication with the Hoverfly flag -disable-basic-auth.
More information on proxy authentication
--https-only
We have added a new flag to both Hoverfly and hoverctl. This flag is --https-only and will set the Hoverfly proxy to only accept HTTPS requests. Any non HTTPS requests will result in 502 Bad Gateway responses.
More information on hoverctl commands
Timeout after failed authentication attempts
In an effort to keep Hoverfly secure when authentication is enabled, we have added a timeout that is triggered after three unsuccessful login attempts. After the three attempts, logging in result in a 429 Too Many Requests and you will have to wait 10 minutes.
More information on proxy authentication
Version bug
Due to the ongoing work to tidy up the public API of the Hoverfly library, a bug was introduced causing our mechanism to update the version number in the library to not correctly up date the version of Hoverfly. This has now been fixed with this release meaning the version number will now be consistent across Hoverfly.
More information on hoverctl commands
v0.11.1
hoverctl targets
We've made a big change to how hoverctl works. "Targets" make it easier to work with multiple Hoverfly instances - this is especially useful if you want to use hoverctl to manage both local and remote instances.
A target stores the configuration for a Hoverfly instance, so you can easily specify which instance to use when executing hoverctl commands by setting the -t / --target flag. If you do not specify a target, hoverctl will use the "default" target. Targets can be viewed using hoverctl targets and can be created using hoverctl targets create my-target.
More information on hoverctl targets
hoverctl login
We have added a new command for logging into an instance of Hoverfly. As part of this change, we've moved the username and password out of the config file. Instead, when using the hoverctl login command, you will be now prompted to enter a username and password.
More information on hoverctl login
hoverctl start --auth
With the introduction of the new hoverctl login command, we have also added the --auth flag to hoverctl start. Using this flag will prompt you to set a username and password which will be used to log in to the Hoverfly instance.
More information on starting Hoverfly with authentication
hoverctl middleware
Based on feedback, we have shortened the output of the hoverctl middleware command. Before, it would print out the full middleware script. Now, it will print the first five lines so that you can confirm that a script has been set. If you want to see the full script, this can be done by using the verbose -v flag.
More information on middleware
hoverctl errors to stdout
It was noticed that hoverctl was not writing errors to the standard error stream. This bug has been fixed in v0.11.1.
More information on hoverctl
v0.11.0
Its been a month in the making. v0.11.0 is here with a bevy of improvements, building on already existing functionality.
Request matchers (including support for XML and JSON matching, XPATH, JSONPATH and regex)
Originally, Hoverfly only supported "recordings". An incoming request had to exactly match a stored request for a response to be returned.
Since the introduction of templates, it was clear that the way we match requests in Hoverfly needed to improve. v0.11.0 brings the first phase of those improvements.
Recordings are now treated like templates, meaning it is even easier and simpler to modify a captured request and turn it into a looser fitting template.
Instead of defining request field values exactly, we have introduced a new set of matchers. Each request field (except headers) will now take an object of matchers. These matchers have allowed us to add new ways of matching data. For example, it is now possible to match a request body based on an XPath expression.
This change has resulted in the Hoverfly schema being updated to v2. When importing an older v1 schemaVersion simulation, Hoverfly will automatically upgrade it to v2.
More information on request matchers
Caching requests
Previous versions of Hoverfly used a cache to store request recordings. The issue with this was you could not cache request templates, meaning a slower response time than with recording.
v0.11.0 has changed the way the cache works. Now, responses are stored against incoming requests meaning Hoverfly should now perform consistently regardless of how "loose" your simulation is.
The cache will be reloaded from your simulation every time you enter simulate mode. We have also added API endpoints for both viewing the state of the cache as well as flushing it.
More information on the logs API
Capture mode and headers
We've changed capture mode so now by default, when you capture requests, request headers ill not be captured. This is due to the way the cache works with hashes of the request. Now, if you want to capture headers, you will need to specify them when setting capture mode.
In hoverctl, we have added two new flags to hoverctl mode which are
hoverctl mode capture --headers "User-Agent,Content-Type,Authorization"
hoverctl mode capture --all-headers
More information on hoverctl
If you are using HTTPS/TLS traffic and have not seen our last release, v0.10.3, we strongly advise looking as it provides instructions on how to replace the expired certificate.
v0.10.3
Greetings, its been a while. We've been very busy preparing v0.11.0 of Hoverfly, which will be coming very soon.
This is an important release for those using HTTPS/SSL traffic with Hoverfly
Updating core/cert.pem
Today (24th March, 2017), the certificate that ships with Hoverfly for HTTPS/SSL traffic expired. This has prompted a new certificate which now has a 5 year expiry.
As a result of this, from v0.10.3 onwards, you will need to remove the current certificate from your certificate truststore and add the new one.
If you cannot or do not want to update your version of Hoverfly, you can work around this by generating new certificates with Hoverfly and setting them manually when starting Hoverfly.
For more information on HTTPS/SSL
hoverctl version
We have updated hoverctl version so it will now report the versions of both hoverfly and hoverctl binaries
For more information on hoverctl commands.