Releases: SpectoLabs/hoverfly
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.
v0.10.2
Its time for a small Hoverfly update. Over the past week, we've been fixing bugs and adding features.
hoverctl errors
With the change to using spf13/cobra, we introduced a bug where "index out of range" errors would be printed when parameters were missing from certain hoverctl commands. This has been fixed to print a nicer error message.
For more information on hoverctl
Authentication on the proxy
We have expanded authentication within Hoverfly. Originally, turning on authentication would only take affect on the API, requiring a JWT token to communicate with Hoverfly. v0.10.2 now introduces authentication to the Hoverfly proxy.
For more information on authentication
Authentication for in-memory Hoverfly
As part of the changes to authentication, we have also enabled the ability to use authentication with an in-memory database. Previously you were restricted to only being able to enable authentication when using BoltDB.
For more information on authentication
Advanced tutorials
With this release, we have created a new section in the documentation for "advanced tutorials". This section includes guides that show how to use Hoverfly in more complex situations. If you have any issues or misunderstandings around the documentation, feel free to raise issues. We are always striving to improve our docs!
For more information on advanced tutorials
v0.10.1
Its been a month since the last release so we've got v0.10.1 ready for you. Since the last release, we've been busy improving the functional tests around Hoverfly and hoverctl, moving hoverctl over to use Cobra as well as fixing a few bugs and adding a new feature.
Query parameter ordering using templates
In v0.10.0, we fixed a bug which meant that query parameters were being compared based on order, meaning that rearranging query parameters would cause matching to fail. Sadly, this fix was only to request recordings. This has now been applied to both templates and recordings, fixing the issue permanently.
For more information on templates
Request bodies on POST and PUT requests
During the refactor of v0.10.0 a bug was introduced that caused the request bodies on POST and PUT requests to be unreadable due to the preparation of bytes before being attached to a HTTP request. This has now been resolved.
Upstream proxy
Thanks to the work of @Bruno-DaSilva, we now have the ability to run Hoverfly behind of another proxy. This opens up the possibility of using Hoverfly in environments where using a proxy is required to communicate outside of your network. Currently, this upstream proxy feature only works with unauthenticated proxies, though we are looking to address this soon.
For more information on setting an upstream proxy
Hoverctl rework
Having moved over to Cobra, we have reorganized the codebase, removed irrelevant commands (delays and templates) and produced more descriptive help text for each of the hoverctl commands.
For more information on hoverctl commands
v0.10.0
It's a new year, so here's a new version of Hoverfly! This version has been in the works longer than expected but as a result, this release is even better than we initially intended.
We had the opportunity to rewrite several parts of the codebase. Some of this time has been spent on refactoring and some has been spent on improvements. Because of this, we've bumped the version number up to v0.10.0.
Alongside the new release, we have rewritten the Hoverfly documentation and are now publishing it to ReadTheDocs. We hope that these changes will make it easier to get up to speed with Hoverfly quickly.
Stick around and let me tell you about the changes.
Middleware API change
We had the opportunity to look into middleware and how its managed within Hoverfly. One of the initial limitations was that the middleware had to be on the host which Hoverfly was running.
This was okay for local development work but as soon as you tried to use a remote Hoverfly instance or even the Hoverfly docker image, setting middleware became difficult.
We have addressed this by changing how you set middleware. Instead of specifying a command, the API now accepts three values: "binary", "script" and "remote". "Binary" is the binary process Hoverfly should run. This should be located on the host machine. As for "script", rather than sending a path to a file, Hoverfly will now accept the contents of the script. Once the script has been received, Hoverfly will write it into the temporary directory, deleting it when it is no longer needed. The "remote" field is for supplying a URL for middleware which can be accessed via HTTP.
This change in API has been reflected in hoverctl. When setting middleware with hoverctl, you are now expected to use the new middleware flags, --binary, --script, --remote.
hoverctl middleware --binary python --script my_middleware.py
For more information on setting middleware: Using middleware to simulate network latency
Changing database default and new hoverctl flag
For a while, there has been an inconsistency between Hoverfly and hoverctl. Starting Hoverfly as a process would default to writing data to the BoltDB request.db file. Starting a Hoverfly process with hoverctl would set Hoverfly to use an in-memory database. This caused confusion for some users. By default, both Hoverfly and hoverctl will now start Hoverfly processes with an in-memory database.
In conjunction with this change, we have also introduced a new --database flag to hoverctl for the times when you do need to persist data with BoltDB.
For more information on hoverctl: hoverctl commands
Consistent HTTP errors from Hoverfly
Through the refactoring, we have standardised the HTTP errors returned by Hoverfly. Previously, when using Hoverfly as a proxy, there were several different style errors that could occur. Now, whenever Hoverfly throws an error, it will return a response with a 512 error code and a nice description of the error. Each error that Hoverfly returns will also be logged, which will be either in the standard out of the Hoverfly process, or captured by hoverctl so they can be viewed with hoverctl logs.
Ordering HTTP request queries
We noticed a bug regarding recorded requests with query parameters. When the HTTP request was being converted in to an internal Request object, there was no sorting on the query parameters. As a result of this, it was possible to record the same request multiple times by changing the order of the query parameters. This version of Hoverfly fixes this by always sorting the query parameters into alphabetical order when converting a HTTP request to a Request object.
For more information on capturing requests and responses Creating and exporting a simulation
v0.9.2
I remember v0.9.1, it felt like it was less than a week ago.
It was, but we have another new version of Hoverfly already! This new version contains a few usability fixes as well as a fix to a bug.
Locked in memory cache bug
This week, we discovered a bug. This bug was only noticeable when running Hoverfly with the in memory database. The problem was, if you made a request to the cache and it failed, the cache would remain locked, making it impossible to ever read or write from the cache without resetting Hoverfly. This has been fixed up now and the in memory cache should not get stuck in a locked state any more.
Pretty JSON
When exporting data to a JSON file with hoverctl, the file it would write would always have the simulation JSON on one line, making it hard to read. Now, hoverctl will write JSON in a more formatted way, making it easier to read your simulations.
For more information on exporting simulations Exporting captured data
Invalid simulation parsing
With v0.9.0, we introduced a new schema for the simulation. This schema is slightly more complicated than the previous. One of the issues we found was that when creating your own simulation files, Hoverfly gave no validation on this schema. Now, when importing a simulation file, if it doesn't match the expected schema, it will now report the error.
For more information on simulations Managing simulation data
hoverctl start reports ports
Another small piece of feedback we had was that it wasn't always clear which ports Hoverfly had started on when using the hoverctl tool. We've updated hoverctl to now log the admin and proxy ports when starting an instance of Hoverfly.
For more information on hoverctl Hoverctl reference