You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As mentioned in #16 (comment), ln-paywall stores invoice metadata in the storage, so it doesn't require the X-Token that paypercall requires. The token in paypercall is used to not only include the invoice ID, but also store the metadata (HTTP method, URL path) in the token, send it to the client, then the client has to include it in the final request so the middleware can read the metadata from the token again and verify it matches the method + path of the current request, so the client can't cheat.
So while ln-paywall doesn't require it, it would be nice to be compatible with paypercall clients. Although I'm not aware of any client-side libraries (other than our own ln-paywall client, which will gain paypercall compatibility with #23), this doesn't mean no client-side code exists (could be just plain HTTP requests), and also it would be nice to offer this compatibility anyway.
So: After #25 is implemented, after which the middleware will accept not only the preimage of a payment, but also the invoice ID, this invoice ID can just be sent as X-Token in the response to the initial request.
I don't think this should be the default though. So make it configurable with some new wall.MiddlewareOptions.
The text was updated successfully, but these errors were encountered:
As mentioned in #16 (comment), ln-paywall stores invoice metadata in the storage, so it doesn't require the
X-Token
that paypercall requires. The token in paypercall is used to not only include the invoice ID, but also store the metadata (HTTP method, URL path) in the token, send it to the client, then the client has to include it in the final request so the middleware can read the metadata from the token again and verify it matches the method + path of the current request, so the client can't cheat.So while ln-paywall doesn't require it, it would be nice to be compatible with paypercall clients. Although I'm not aware of any client-side libraries (other than our own ln-paywall client, which will gain paypercall compatibility with #23), this doesn't mean no client-side code exists (could be just plain HTTP requests), and also it would be nice to offer this compatibility anyway.
So: After #25 is implemented, after which the middleware will accept not only the preimage of a payment, but also the invoice ID, this invoice ID can just be sent as
X-Token
in the response to the initial request.I don't think this should be the default though. So make it configurable with some new
wall.MiddlewareOptions
.The text was updated successfully, but these errors were encountered: