Download the PHP package cboxdk/laravel-webhook-signature without Composer

On this page you can find all versions of the php package cboxdk/laravel-webhook-signature. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of cboxdk/laravel-webhook-signature

Informations about the package laravel-webhook-signature

Cbox Webhook Signature

Webhook signature verification for Laravel, with drivers for the providers you actually receive from — and outbound signing that uses the same code.

ci

Receiving

Sending

Signed by Guzzle middleware at send time, so the bytes that are signed are the bytes that are sent. No encoded body to keep in a variable and hand to two places.

Bundled schemes

Name Signed bytes Digest Encoding
github raw body SHA-256 hex
stripe {timestamp}.{body} SHA-256 hex
slack v0:{timestamp}:{body} SHA-256 hex
shopify raw body SHA-256 base64
standard-webhooks {id}.{timestamp}.{body} SHA-256 base64
twilio URL + sorted parameters SHA-1 base64
mailgun {timestamp}{token} SHA-256 hex
postal raw body (RSA, public key) SHA-256 / SHA-1 base64
cbox {timestamp}.{body} SHA-256 hex

Anything else: describe it in config with the generic HMAC driver, or register a class.

What it does that a hand-rolled verifier does not

Secret rotation. You cannot rotate a webhook secret atomically — sender and receiver deploy separately — so an endpoint holds a set of live secrets, and reports which one verified so you know when the old one can safely go.

Replay defence. Timestamp binding where the provider supports it, plus optional single-use enforcement against a shared store. Off by default, because a guard against a per-node cache reports success while enforcing nothing.

Typed failure reasons. "Our secret is missing" is distinguishable from "someone sent a bad signature" — in your logs, and in the status code: 401 for the caller's mistake, 500 for ours, so a provider retries a misconfigured receiver rather than discarding events.

The provider details. Stripe sends several valid signatures during a rotation. The Standard Webhooks secret is base64 behind a whsec_ prefix. Shopify is base64 where the others are hex. Twilio signs the URL, sorted byte-wise, with SHA-1. GitHub's legacy SHA-1 header is refused rather than accepted alongside SHA-256, and Postal's SHA-256 header — when present — is the only one checked, so a corrupted strong signature cannot be downgraded to the weak one.

Testing helpers that sign with the production code path:

What it deliberately is not

No migrations, no models, no queued jobs, no webhook_calls table. Storing deliveries and processing them are decisions your application has already made; a library that made them again would be something to fit around rather than something to drop in.

Conformance

Every bundled scheme is tested against a signature produced by an implementation other than this one — a round trip cannot catch a misread specification, because both halves are wrong the same way.

github, slack, standard-webhooks and twilio use the worked examples their providers publish; the HMAC primitive is checked against RFC 4231 vectors. stripe, shopify, mailgun, postal and cbox are checked against signatures generated by the provider's own SDK, by the openssl CLI, or by the independently written signer already deployed in the Cbox billing service. docs/security/conformance.md names the source for each.

Nothing here is hand-rolled cryptography: MACs use PHP's hash_hmac() and hash_equals() in one class, and the asymmetric path uses openssl_verify() in another.

Requirements

PHP 8.4+, Laravel 12 or 13. See docs/requirements.md.

Documentation

docs/index.md — quickstart, per-provider recipes, rotation, replay protection, extension points, threat model.

Development

License

MIT. See LICENSE.

All versions of laravel-webhook-signature with dependencies

PHP Build Version
Package Version
Requires php Version ^8.4
ext-json Version *
illuminate/contracts Version ^12.0 || ^13.0
illuminate/http Version ^12.0 || ^13.0
illuminate/support Version ^12.0 || ^13.0
guzzlehttp/promises Version ^2.0 || ^3.0
psr/http-message Version ^1.1 || ^2.0
psr/log Version ^3.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package cboxdk/laravel-webhook-signature contains the following files

Loading the files please wait ...