Research
Security News
Malicious npm Packages Inject SSH Backdoors via Typosquatted Libraries
Socket’s threat research team has detected six malicious npm packages typosquatting popular libraries to insert SSH backdoors.
hs-pact-mock_service
Advanced tools
This codebase provides the HTTP mock and stub service used by implementations of Pact. It is packaged as a gem, and as a standalone executable for Mac OSX and Linux and Windows.
The mock service provides the following endpoints:
All requests to the "administration" endpoints listed above must contain the header X-Pact-Mock-Service: true
to allow the mock service to know whether the request is an administration request or a request from the actual consumer code.
As the Pact mock service can be used as a standalone executable and administered via HTTP, it can be used for testing with any language. All that is required is a library in the native language to create the HTTP calls listed above. Check out docs.pact.io for a list of implemented languages. If you are interested in creating bindings in a new language, have a chat to one of us on the pact-dev Google group.
Use the Pact standalone executables.
Use the pact gem if you would like the full Pact DSL, mock service and verification functionality in your ruby project.
Otherwise:
$ gem install pact-mock_service
$ pact-mock-service --consumer Foo --provider Bar --port 1234
Or add gem "pact-mock_service"
to your Gemfile then run:
$ bundle install
$ bundle exec pact-mock-service --consumer Foo --provider Bar --port 1234
Run pact-mock-service help
for command line options.
Each mock service process is designed to mock only ONE provider for ONE consumer. To mock multiple providers, you will need to start a process for each provider. The lifecycle of a mock service instance during a test suite execution is as follows:
Each mock service instance can only handle one test process/thread at a time. If you wish to run multiple test threads in parallel, you will need to start each mock service instance on a different port, and set the --pact-file-write-mode
to merge
(see usage notes below).
Usage:
pact-mock-service service
Options:
[--consumer=CONSUMER] # Consumer name
[--provider=PROVIDER] # Provider name
-p, [--port=PORT] # Port on which to run the service
-h, [--host=HOST] # Host on which to bind the service
# Default: localhost
-d, [--pact-dir=PACT_DIR] # Directory to which the pacts will be written
-m, [--pact-file-write-mode=PACT_FILE_WRITE_MODE] # `overwrite` or `merge`. Use `merge` when running multiple mock service instances in parallel for the same consumer/provider pair. Ensure the pact file is deleted before running tests when using this option so that interactions deleted from the code are not maintained in the file.
# Default: overwrite
-i, [--pact-specification-version=PACT_SPECIFICATION_VERSION] # The pact specification version to use when writing the pact
# Default: 2
-l, [--log=LOG] # File to which to log output
-o, [--cors=CORS] # Support browser security in tests by responding to OPTIONS requests and adding CORS headers to mocked responses
[--ssl], [--no-ssl] # Use a self-signed SSL cert to run the service over HTTPS
[--sslcert=SSLCERT] # Specify the path to the SSL cert to use when running the service over HTTPS
[--sslkey=SSLKEY] # Specify the path to the SSL key to use when running the service over HTTPS
Start a mock service. If the consumer, provider and pact-dir options are provided, the pact will be written automatically on shutdown (INT).
See script/example.sh for an executable example.
You can find more documentation for the mock service in the repository wiki.
If you need to use the mock service with HTTPS, you can use the built-in SSL mode which relies on and generates a self-signed certificate.
$ pact-mock-service --port 1234 --ssl
If you need to provide your own certificate and key, use the following syntax.
$ pact-mock-service --port 1234 --ssl --sslcert PATH_TO_CERT --sslkey PATH_TO_KEY
Read the wiki page on CORS.
The pact-stub-service allows you to reuse interactions that have been generated in previous tests. The typical situation would be to generate your pact file using unit tests, and then use the pact stub service for your higher level integration/ui tests. To help reduce the number of interactions that need verifying, you will want to use flexible matching on both requests and responses.
Unlike the mock service, which has a Ruby DSL for managing its lifecycle, the mock service can currently only be started from the command line, so you will need to start/background/kill the process yourself. If this is causing problems, please raise it in the pact-dev google group and we can discuss potential enhancements.
Usage:
pact-stub-service PACT_URI ...
Options:
-p, [--port=PORT] # Port on which to run the service
-h, [--host=HOST] # Host on which to bind the service
# Default: localhost
-l, [--log=LOG] # File to which to log output
-o, [--cors=CORS] # Support browser security in tests by responding to OPTIONS requests and adding CORS headers to mocked responses
[--ssl], [--no-ssl] # Use a self-signed SSL cert to run the service over HTTPS
[--sslcert=SSLCERT] # Specify the path to the SSL cert to use when running the service over HTTPS
[--sslkey=SSLKEY] # Specify the path to the SSL key to use when running the service over HTTPS
Description:
Start a stub service with the given pact file(s). Pact URIs may be local file paths or HTTP.
Include any basic auth details in the URL using the format https://USERNAME:PASSWORD@URI.
Where multiple matching interactions are found, the interactions will be sorted by
response status, and the first one will be returned. This may lead to some non-deterministic
behaviour. If you are having problems with this, please raise it on the pact-dev google group,
and we can discuss some potential enhancements.
Note that only versions 1 and 2 of the pact specification are currently fully supported.
Pacts using the v3 format may be used, however, any matching features added in v4 will
currently be ignored.
See CONTRIBUTING.md
FAQs
Unknown package
We found that hs-pact-mock_service demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 5 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket’s threat research team has detected six malicious npm packages typosquatting popular libraries to insert SSH backdoors.
Security News
MITRE's 2024 CWE Top 25 highlights critical software vulnerabilities like XSS, SQL Injection, and CSRF, reflecting shifts due to a refined ranking methodology.
Security News
In this segment of the Risky Business podcast, Feross Aboukhadijeh and Patrick Gray discuss the challenges of tracking malware discovered in open source softare.