I'm sorry. Did you say v2?
Yes. v2! (It's been five years, after all)
Oh dear. How much time is it going to take me to "upgrade" my code?
None. v2 is 100% backwards compatible with v1
Wait, what? Then why did you bump the major version?
Because v2 is Yuge!
This release opens all kinds of exciting doors.
See below for details, but there are three major reasons to upgrade.
- You can now create custom protocol implementations in any language of your choice.
- The injection interface changed (don't worry, you can still use the old interface if you like. I'm not rude, after all).
- I fixed an embarrassing security flaw in all v1 versions using
- The biggest change is how protocol implementations work. In all v1 versions, they worked, but
adding a new one was difficult because of some unfortunate early design decisions. Those decisions
have been painstakingly reversed. You can now add a
custom protocol in any language with a very
simply API to talk back to the mountebank server. The protocol implementation will show in the logs
no differently than a built-in protocol implementation like
http, but will be out of process to mountebank itself. You tell mountebnak about your custom implementation with the new
--protofilecommand line flag. This is Yuge!
- Over time, the injection functions took on new parameters.
This was unfortunate because it became
difficult to remember the order of the parameters and because there were actually two different types
stateparameters passed into the response injection function (I never documented one. The documented one did not share state with predicates; the undocumented one did). While you can continue to use the old interface, the new interface is much cleaner, accepting a single JSON parameter that contains all relevant information. That interface now cleanly shares state between predicate and response injection and allows for much easier evolution of injection functions (including adding async capability to predicate injection and decorate behaviors).
- Injection is useful but dangerous, and you should ALWAYS take steps
to secure yourself from attackers using an injection-enabled mountebank. The easiest way to do that is with
--localOnlyCLI flag, which limits all connections to the loopback interface (e.g., localhost). You should ALWAYS do that when running mountebank directly on your developer machine, and use the
--ipWhitelistflag in other scenarios. Unfortunately, neither of these flags worked in v1. I'm sorry. That's an embarrassing security vulnerability. They are both verified by a series of automated tests now, and verified to work with both the mountebank server itself and all imposter sockets.
- The result from
GET /imposters/:port?replayable=truenow returns the value of
- Setting the
--mockCLI flag no longer changes the imposter-level value of
--hostcommand line flag wasn't being reflected in the logs or mountebank URLs, and it wasn't applying to imposters.
- The tcp protocol page took way too long to load due to page weight (there is an embedded test on the page that required the page weight). That has been fixed.
- The TCP proxy now respects the
- HTTP/S servers no longer time out if a
waitbehavior was set to more than about 2 minutes
- JSON bodies with
nullsnow work with
- SMTP now works with an empty
Many thanks to the following kind folks for help with this release, either through bug reports, suggestions, or direct code contributions:
- Aleksandar "Bearclaw" Serifimoski
- Santiago Vasquez
npm install -g firstname.lastname@example.org
|Simply unpack and run
mb from inside
/usr/local/bin, which is generally in the
|source tarball if you roll that way.
Windows path limitations
*mountebank wishes very much for your Windows experience to be hassle-free, but he is simply not qualified to address a particular constraint of Windows Explorer. For legacy reasons, some Windows applications, including most notably Windows Explorer, have a maximum number of characters allowed in a path of 260 characters. As mountebank writes these words, the longest path he includes in the zip files is around 175 characters. The zip file name, which is likely to represent itself as two nested directories if you use the defaults to unzip it, will be around 25 characters. That gives you very little wiggle room. If you unzip the file in your users directory, you may very likely get an error because of this constraint.
The following solutions will all work:
- Unzip to the root of your C: drive (or a similar small path)
- Use 7zip to unzip the file instead of Windows Explorer
npmto install mountebank instead of the zip file