l402_middleware
A middleware library for rust that uses L402, formerly known as LSAT (a protocol standard for authentication and paid APIs) and provides handler functions to accept microtransactions before serving ad-free content or any paid APIs. It supports Lightning Network Daemon (LND), Lightning Node Connect (LNC), Core Lightning (CLN), Eclair, Lightning URL (LNURL), Nostr Wallet Connect (NWC), and BOLT12 for generating invoices.
Check out the Go version here: https://github.com/getAlby/lsat-middleware
The middleware:-
- Checks the preference of the user whether they need paid content or free content.
- Verify the L402 before serving paid content.
- Send macaroon and invoice if the user prefers paid content and fails to present a valid L402.
It also supports location-scoped ("realm") tokens via caveats::RequestBinding — one payment can authorize a whole route rather than a single path — and server-side settlement detection via LNClient::lookup_invoice, so clients that can't return a usable preimage still work.
Settlement lookup is available on LND, CLN, BOLT12, and Eclair, and on NWC where the wallet implements the optional NIP-47 lookup_invoice. LNURL and LND over the LNC mailbox have no way to ask, and return an error. Settlement is always taken from the node's own status: a wallet knows the preimage of an invoice it minted before anyone pays it, so the preimage alone never counts as proof.
L402 Header Specifications
| Header | Description | Usage | Example |
|---|---|---|---|
| Accept-Authenticate | Sent by the client to show interest in using L402 for authentication. | Used when the client wants to explore authentication options under L402. | Accept-Authenticate: L402 |
| WWW-Authenticate | Sent by the server to request L402 authentication, providing a macaroon and a payment invoice. | Used when the client must pay or authenticate to access a resource. | WWW-Authenticate: L402 macaroon="MDAxM...", invoice="lnbc1..." |
| Authorization | Sent by the client to provide the macaroon and preimage (proof of payment) to access the resource. | Used by the client after payment or authentication to prove access rights. | Authorization: L402 <macaroon>:<preimage> |
Caveats: what a token is bound to
A macaroon carries caveats that limit where it can be spent. The crate understands four:
| Caveat | Meaning |
|---|---|
RequestPath = /exact/path |
Valid for exactly one URL |
Realm = name |
Valid for every path the server maps to that realm |
RequestMethod = GET |
Valid for one HTTP method |
ExpiresAt = <unix seconds> |
Valid until an absolute time |
RequestPath and Realm are alternatives — a token carries one or the other,
never both. Build them with caveats::RequestBinding rather than by hand, so
minting and verification cannot drift apart:
use RequestBinding;
// Exact path — one payment buys one URL. The default.
let binding = path;
// Realm — one payment buys every route naming "library".
let binding = realm;
// Either can expire.
let binding = binding.with_expiry;
let caveats = binding.to_caveats; // mint these into the macaroon
Verify with the same binding:
use l402;
verify_l402_binding?;
Bind the method. A binding always carries RequestMethod, so a token bought
for GET will not satisfy a POST. Hand-rolled caveat lists frequently omit
this, and a token that ignores the method is a token that can be replayed
against a different handler on the same path.
Use verify_l402_binding where scope matters. The older verify_l402
exact-matches whatever caveat strings you hand it. It cannot evaluate
ExpiresAt — it compares the string, so an expired token still matches — and it
has no notion of realms. verify_l402_binding enforces scope and method by
exact match, checks expiry against the clock, and rejects any scope or method
predicate it was not given rather than letting it pass.
That last part is the security-critical one: a verifier that lets an unknown
RequestPath or Realm predicate fall through to "satisfied" will accept a
token minted for a different route. RequestBinding::verifier is the single
place that guard lives, and the bypass tests at the bottom of caveats.rs cover
it.
Installation
Add the crate to your Cargo.toml:
[]
= "2.3.3"
By using the no-accept-authenticate-required feature, the check for the Accept-Authenticate header can be bypassed, allowing L402 to be treated as the default authentication option.
[]
= { = "2.3.3", = ["no-accept-authenticate-required"] }
The Rocket integration (Fairing, request guards, demo server) is behind the rocket feature, which is on by default. Library consumers that only call the handler functions (e.g. ngx_l402) can disable default features to drop rocket from their dependency tree:
[]
= { = "2.4.0", = false }
Note: the
rocketfeature gate is not in a published release yet — 2.3.3 on crates.io predates it, so on 2.3.3default-features = falseis a no-op and rocket stays in the tree. This applies from the next published version.
Ensure that you create a .env file based on the provided .env_example and configure all the necessary environment variables.
Example
extern crate rocket;
use Json;
use Serialize;
use Status;
use Request;
use dotenv;
use env;
use Arc;
use Client;
use ;
use RequestBinding;
const SATS_PER_BTC: i64 = 100_000_000;
const MIN_SATS_TO_BE_PAID: i64 = 1;
const MSAT_PER_SAT: i64 = 1000;
// Caveats the macaroon will carry. Customize as authentication needs require —
// but build them with RequestBinding, which also binds the HTTP method so a
// token bought for GET cannot be replayed against POST on the same path.
pub async
Testing
Run tests with:
cargo test --verbosefor standard testscargo test --verbose --features "no-accept-authenticate-required"to run tests with accept-authenticate header requirements disabled