lightninglabs / lightninglabs/aperture

Aperture as a library - nice to have's

Open
#45 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
268
Forks
78
Avg merge
22h 25m
Merged PRs (30d)
1

Description

Hey guys! Thanks again for aperture, really interested mostly in using it as a library than a proxy over existing services. Not sure if that's the direction you want to be open to or not but there was some things I had in my local project that I thought would be good to discuss & potentially contribute back as feedback.

First is mostly around exports. There's some things in aperture that I'd like to not have to copy/paste into my project, so things like `newStaticServiceLimiter` and `LndChallenger.client` would be great to have exported.

Along these lines, another improvement that would be nice to have would be to allow the invoice checker to be optional. I'm kind of curious why that was introduced actually, shouldn't preimage always be good enough to prove an invoice was paid? Unless of course someone accessed the node and viewed the preimage themselves, or created the invoice with a preimage. I think those are edge cases that may be nice to ignore without having to create the classes myself with empty methods fulfilling the `InvoiceChecker` interface.

I created a PR here with some of these changes - mostly as a way to visualize what I mean and discuss. Happy to clean up or go a different direction with some of the code to produce a similar result. https://github.com/lightninglabs/aperture/pull/44

And some examples of how I use the proposed code:

```
func (l *lightningAuth) VerifyLightningAuth(o *AuthOptions) (bool, error) {
// challenger
genInvoiceReq := func(price int64) (*lnrpc.Invoice, error) {
return &lnrpc.Invoice{
Memo: "LSAT",
Value: price,
}, nil
}
challenger := &aperture.LndChallenger{
Client: l.lndClient,
GenInvoiceReq: genInvoiceReq,
VerifyInvoiceStatusFunc: VerifyInvoiceStatusNil,
}

// limiter
s := lsat.Service{
Name: o.ServiceName,
Tier: lsat.BaseTier,
Price: o.Price,
}
limiter := &aperture.StaticServiceLimiter{}
if o.Capabilities != "" {
limiter.Capabilities = map[lsat.Service]lsat.Caveat{
s: lsat.NewCapabilitiesCaveat(s.Name, o.Capabilities),
}
}

authenticator := auth.NewLsatAuthenticator(
mint.New(&mint.Config{
Secrets: l.secretStorage,
Challenger: challenger,
ServiceLimiter: limiter,
}),
challenger,
)

return authenticator.Accept(o.H, o.ServiceName), nil
}

func (l *lightningAuth) NewChallengeHeader(o *AuthOptions) (http.Header, error) {
// challenger
genInvoiceReq := func(price int64) (*lnrpc.Invoice, error) {
return &lnrpc.Invoice{
Memo: "LSAT",
Value: price,
}, nil
}
challenger := &aperture.LndChallenger{
Client: l.lndClient,
GenInvoiceReq: genInvoiceReq,
VerifyInvoiceStatusFunc: VerifyInvoiceStatusNil,
}

// limiter
s := lsat.Service{
Name: o.ServiceName,
Tier: lsat.BaseTier,
Price: o.Price,
}
limiter := &aperture.StaticServiceLimiter{}
if o.Capabilities != "" {
limiter.Capabilities = map[lsat.Service]lsat.Caveat{
s: lsat.NewCapabilitiesCaveat(s.Name, o.Capabilities),
}
}

authenticator := auth.NewLsatAuthenticator(
mint.New(&mint.Config{
Secrets: l.secretStorage,
Challenger: challenger,
ServiceLimiter: limiter,
}),
challenger,
)

return authenticator.FreshChallengeHeader(o.R, o.ServiceName, o.Price)
}
```
I'm making the connection to LND myself, so exporting `Client` would be nice so I don't have to go through creating the challenger via `NewLndChallenger` way. Also I'm not going to be consistently connected to the possibly many lnd clients I'd be creating invoices from, so I'm simply only caring about preimage matching macaroon (so not constantly streaming invoice statuses or caring about invoice checking).

Anyways, thoughts? I'm okay keeping a fork for what could be very edge case/specialized behavior specific to me. Just thought I seen some thing that made me want to talk about contributing back. Going a different direction to establish the same goals is okay too, just got a quick mvp of what I thought I needed myself. I have some other ideas around capabilities and constraints that may be nice to chat about in another issue in the near future too.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the proposed changes in PR #44 and the issue's examples for exported StaticServiceLimiter and LndChallenger.Client usage. Clarify whether both exports and optional invoice checking are desired, then confirm the intended API and behavior before treating the work as done.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
api, backend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.